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EDITOR'S COMMENTS 



Welcome to the holidays. We don't 
have any special seasonal articles 
for you in this issue. However I did 
get a welcome gift as I was finish- 
ing up the magazine. Dave Thomp- 
son the owner of MicroComucopia 
sent me all his Kaypro disk. Now 
TCJ is ready to sell you those 
Kaypro disk that you have been 
waiting to get. I am printing half 
the list in this issue, with the second 
part next time. That list is on the 
last few pages of the magazine. 

Our writers have been busy as usual 
producing some great material for 
you. We have Jay Sage continuing 
his discussion on Language Inde- 
pendence. Tim McDonough is back 
with a report on microprocessor 
development tools. Rick Rodman 
comments on Minix and UZI (a 
Z80 UNIX?). We start out Kaypro 
support with Mr. Kaypro by Charies 
Stafford. Herbert Johnson explains 
how to get started bringing up an 
S-100 system. 

We have two special articles for 
you, one to bring back those fiinda- 
mentals of electronics, and one on 
multitasking in Forth. Clem Pepper 
show you a great use for "C", by 
explaining and giving you the source 
code for a simple program to calcu- 
late the resistors and capacitors 
needed for timers and monostable 
oscillators. 

Brad Rodriguez tells us all and more 
about the Forth multitasker. This in 



depth study should answer ques- 
tions about Forth' s multitasker, as 
well as giving examples and alter- 
natives to the way F83 works now. 

Doing Business 

I have been working very hard to 
get TCJ's production problems un- 
der control. The subscription prob- 
lems however continue. It is be- 
coming apparent that a new mailing 
label program is needed. I have been 
using the old program, but far too 
many items are not handled cor- 
rectly. For the reader this means 
more time until mailing related prob- 
lems go away. Please bear with me 
as I try and correct this problem. 

When phoning TCJ please remem- 
ber that my office hours are 9 to 11 
PM week nights in California. My 
employer has dropped the alternate 
Fridays off, so I no longer can make 
daytime phone calls except on week- 
ends. This makes doing business 
very difficult, but there are no alter- 
natives at the present. 

I will not be teaching next year and 
so two more nights a week will be 
available to catch up on mail. Cur- 
rently I only answer mail and phone 
messages by letter between issue 
preparations. It goes something like 
this: edit stories non-stop; page set 
the stories in a rush, do a panic 
collate the material into a magazine 
(ignoring errors in hopes of being 
only a week or two late and not two 



months behind); take to printer 
quickly; update last months worth 
of phone calls and subscription 
updates; print labels before printer 
has issues ready (takes 3 hours to 
print if no errors happen); get is- 
sues back and put labels on over 
two very long nights; take time off 
fi-om work to mail out the issues; 
relax for one day; start contacting 
writers; do mail; start again. 

To add to all this frantic chaos, I 
must dig into my own pocket each 
issue to cover expenses beyond sub- 
scription returns. I have calculated 
cost at $2.75 each to mail in the 
US. So far renewals and new sub- 
scriptions have not been keeping 
pace with expenses (about 30% 
short). The results of this will be 
subscription increases next year, 
about a dollar per issue for now. 
This is far short of what some have 
suggested I charge ($50 a year), 
but well within what others are 
charging for like publications. As 
always I am open to suggestions 
and alternative proposals. 

Till next issue, read, enjoy, and be 
merry. Bill Kibler. 
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All Readers 

MINI Articles 



8/11/92 

Dear Mr. Kibler 

I just received the extra "free" copy of 
TCJ, and was fairly pleased at the changes 
discussed. 

My perspective on things; 

I am one of those that has been looking 
for a good alternative to the Byte/Cre- 
ative Computing of yesteryear. Today's 
Byte is not much more than PC Maga- 
zine with a few features on bigger per- 
sonal computer systems. 

Dr. Dobbs Journal often has interesting 
material, but has headed very much into 
software engineering, which may be 
useful, but isn't much tun. 

I saw one issue of MicroCornucopia, 
which seemed to be just about perfect in 
having coverage of various levels of 
"hobby computing." Even the articles 
that 1 didn't have any thoughts on imple- 
menting were highly interesting. They 
even had some people who could actu- 
ally write, and an editor with a good 
sense of humor. I understand that that 
issue may have been the last one, alas! 

Then I heard about TCJ, which was a 
little more hardware oriented than 1 am, 
and was foremost a CP/M and Z-System 
journal. But 1 heard that they were head- 
ing towards more support of Forth, and 
tried to do various sorts of coverage. 
Sounded pretty neat. 

After a year, it seemed to be a little too 
oriented towards CP/M stuff, in which 1 
have relatively little interest. Issue #56 



seems to be better oriented, from my 
perspective. 

I'll just quickly describe my computer 
system: 

- Atari Mega STe, 4MB RAM 

- SCSI Hard drive (85MB, mostly foil!) 

- Using GNU things like GCC (GNU C), 
and perl (Practical Extraction and Re- 
porting Language OR Pathologically 
Eclectic Rubbish Lister ...Probably wor- 
thy of an article in TCJ.) 

- Multitasking system called MiNT 
(MiNT is Not TOS) 

People that want to do UNIX-like stuff 
on the ST should check out MiNT (I can 
send out copies - it uses the GNU Copyleft 
license, and is free!). It tends to crash 
quite a bit on me, which is partly a 
fonction of having a lot of system utili- 
ties that "break OS rules" and a fimc- 
tion of working on fairly complex code 
that crashes far too much. . .It would work 
better with an MMU, I'm sure. 
It's probably a more viable system than 
MINIX, particularly since it actually has 
some Atari support, and extensive de- 
veloper support on Usenet. 

- The LATEX typesetting system. Its 
fundamental purpose is to do "nasty 
math," like: 

(editor comment:... It's does such a nice 
job of nasty display that I can Y even try 
matching them... take my word it looked 
great in his letter...) 

It produces VERY nice output, and is 
extremely portable. 

- Many implementations of Forth for the 
Atari ST 

I know of only two version that I don't 
have, one being the Forth-83 for the 
68000, and the other being some f-83 
commercial variant called MutliForth. I 
probably ought to do an article for TCJ 



on the various implementations that I do 
have. (Mitch Bradley's Forthmacs, The 
Australian FORST, H&D Forth, 4xForth) 
each certainly has advantages and disad- 
vantages. 3 of these are commercial, so 
that people might be quite pleased if 
they got reviewed. (There would be some 
kind words for each one of the bunch.) 

My current "big project" is some nu- 
merical analysis work, solving some 
fairly large scale optimization problems. 
More specifically, 1 am nearing comple- 
tion of a Master's thesis on the topic: 
' 'Using Interior Point Methods to Solve 
the Multicommodity Network Flow Prob- 
lem. ' ' When I'm not writing letters, I'm 
debugging code for some combination of 
linear programs and network flows. 

One thing that is notable about all this 
stuff is that unlike the 8 bit users, I don't 
have any important applications that are 
NOT memory intensive. There isn't even 
one program (of importance) that takes 
less than 64K of RAM. The various com- 
pilers vary fairly wildly in memory con- 
sumption - GCC would not work when 
I had only 2MB, and I think it would be 
happier if I had more memory. Perl dy- 
namically generates hash tables to build 
"association lists," and may take up a 
whole lot of RAM, or (relatively!) little 
if there's only a little data. 

Something that I would like to see/get is 
some sort of small single-board com- 
puter that could act as an experimental 
controller or perhaps as a home-control 
coprocessor within my computer system. 
I've got this HUGE case in which my 
hard drive is mounted. There's power to 
spare, cables, and quite a lot of space. 
Every time I look around, I see another 
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different single board computer that 
wants to be used. 

At this time, money is certainly a major 
restriction for me. The question is: Should 
I find some 803 1/5 1 Kit, find some way 
of getting some old Z80 design to run, or 
maybe pick up one of those New Micros 
"Single Chip Computers?" There's no 
old code for me to support - 1 can go for 
something new without breaking any- 
thing. What would be nicest would be to 
have something running Forth, with an 
extra serial line to tether to either the 
VTIOO or the ST. I'd like to see an 
article discussing some of the pros and 
cons of different small controllers. 

I hope that this information is useful, 
and that it can help (to some extent) to 
guide where things go at TCJ. I'd cer- 
tainly be willing and able to write an 
article or two, within the areas that I 
know. I've mentioned a couple of my 
ideas - if you have any thoughts, I 
wouldn't mind hearing them! 

Yours truly, Christopher Browne, Uni- 
versity of Ottawa 

Well Mr. Browne: 

I was unable to print your letter last 
issue, but your letter only seems to get 
better with time. Since you sent it, I have 
been working on finding reasons and 
applications for classic systems Filling 
your slot in the disk cabinet would be a 
great place for an AMPRO or YASBEC 
systems. You might consider using it for 
a print spooler as the LATEX output 
looks like it might require lots of printer 
function commands. 

However 1 might also recommend the 
Motorola trainers and sample boards. 
They were selling the 68HC16 demo 
board for $168. Not only do you get a 
full system, but they give you TONS of 
literature about the chip and support 
software (includes PCDOS based assem- 
bler and debuggers). 

Being an Atari ST owner I know of their 
great cost/use ratio. I have MINIX for 
the ST and have found it lacking in some 
areas. Your MINT sounds like something 
I would like to try, or better yet have you 



tell us all about it. I guess my main 
question is source code, does it come 
with it all? 

You are also correct in that TCJ readers 
are interested in more than CP/M. I am 
finding out that some of our information 
is not available in any other magazine. 
That is one reason I keep saying we are 
and will continue to be the only maga- 
zine supporting classic systems. I am 
sure you have found out that most maga- 
zine are treating the Atari ST as a clas- 
sic system as well. So if you want to do 
that article about Forth systems on ST's, 
we are ready and waiting. Thanks for all 
the comments. BDK. 

October 5, 1992 

Dear Bill: 

I picked up the TCJ survey from GENIE 
yesterday and will answer by mail. 

The first issue of TCJ under your lead- 
ership came the other day. I confess to a 
fair degree of disappointment in it. Hav- 
ing subscribed to the Journal since about 
issue 37, 1 have a great appreciation for 
what it has contributed to my knowledge 
and skill as a programmer in Z80. (My 
contributions to the Z-System commu- 
nity include ZDB, ZDT, ZBIB, and 
lOPZXR). I also enjoy other articles (al- 
though I am not at all into FORTH). My 
disappointment has more to do with the 
quaUty of the writing and editing than 
with the content. Your "Next Ten 
Years" on page 5 of issue #56 abounds 
with typos, grammatical and punctua- 
tion errors, and awkward, confused, and 
incomplete sentences. Maybe this does 
not matter to engineer types ~ which I 
am not ~ but a technical journal ought 
to be clear and accurate. I have some 
background as a writer, having written 
and reviewed for the late and lamented 
PROFILES and MicroCornucopia. 

Now to answer the questions in your 
survey: 

1) Why do I read TCT! My main interest 
is in Z-Systems, ZCPR3, Z80 stuff, al- 
though I generally read everything else. 



I never miss Jay Sage's column. I miss 
terribly Bridger Mitchell's great contri- 
butions. Al Hawley and Terry Hazen are 
electronic friends whose articles are al- 
ways helpful. 

2) What do I want from TCn See #1. 

3) How much equipment do I have? 
Kaypro ir83, modified with TurboRom, 
42 Meg harddrive, modem, printer, 
Macintosh. I also use MS-DOS stuff at 
work. 

4) Would I still subscribe to TCJ at $50/ 
yr? $100/yr? Price of subscription will 
have very little bearing on my decision 
to renew when the time comes. Content 
of interest to me and quaUty and clarity 
of writing will determine. 

5) Is there another magazine's format 
you like better? No comment. 

6) What do I want? Quality articles — in 
some cases longer may be better to cover 
subject adequately. I like regular writers 
who have something to say. I lean more 
toward software than hardware topics. 
Advanced and beginner topics are both 
appreciated. I was once a woeful begin- 
ner. 

7) What do I hate most about TCJl I 
think I have already covered this ques- 
tion except for one thing. I really hate 
the blue cover. 

Bill, I know I've been fairly critical. I do 
want TCJ to succeed, and I'd be happy 
to help out in some way as a copy editor 
or consultant if that fits into your needs. 

All the best to you and TCJ. 

Joseph I. Mortensen, Midland, MI. 

Thanks for your sincere comments Jo- 
seph. 

It seems my panic in putting #56 to- 
gether caused more errors than I thought 
I am trying to cut them down, but must 
confess it will take several issues and 
freeing up of time to correct the prob- 
lems I have asked my contributing edi- 
tors to act as reviewers of articles, but 
alas they too are very busy. In the near 
future I may call on you to review ar- 
ticles, or better yet help in getting them 
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and making sure they fully explain the 
topic for all levels of our readers. 

We will be raising our rates after the 
first of the year. Mostly to offset and 
correct foreign mailing rates, but also to 
try and get some extra money so our 
writer might get some compensation for 
their hard work. As to your favorite 
writers, I only hope they see this and 
contact you to learn what you might like 
to see them comment and report on. I 
have asked all our past and present writ- 
ers for articles, but it is up to them and 
not me as to when I have something of 
their 's to publish. 

You might consider writing something 
about your Z-System programs and us- 
ing Z-products. Many of our readers are 
real beginners to CP/M and ZCPR and 
I am sure would love to hear about your 
early beginner projects As always, 1 am 
grateful you took the time to respond to 
my survey. Thanks for your response 
and support of the Z-community. BDK. 

Sept. 24, 1992 

Dear Bill, 

I have recently introduced a few people 
to Z-system over here, at the same time 
I have sent details of TCJ lo them. Some 
of them have expressed an interest in 
TCJ but do not want to subscribe without 
seeing what it is like for themselves, 
they to far away from me to see one of 
my copies. I am enclosing a list of Z- 
system users and interested people, you 
might like to send them an introductory 
copy. 

I have all TCJ from number 25 up to 
date and have recently ordered all the 
available back issues. 

I own a SB180FX with ETS board and 
unused GT180 graphics board which 1 
was hoping to use as a terminal but it is 
beyond me to get it sorted, I have the 
denied Turbo Module 2 with graphics 
toolbox, but it needs some software to 
get the lot together. Has anybody used 
this board? I have had no mention of it 
since it was introduced in Byte several 
years ago. I also have an Amstrad 



PCW8512 which runs Z3plus and 
doubles as a terminal for the SB180FX. 

Keep up the good work with TCJ as 
without it 1 would have given up com- 
puters long ago or worse still use and 
IBM clone. 

Your Sincerely, Mark Minting, Suffolk, 
England. 

Thanks for the names Mark. 

I sent all the people on your list a trial 
subscription. They should have gotten 
issue #57 by now, but knowing that the 
surface mail takes forever to get to Eu- 
rope they could still be in shipment. I 
have decided to reprint (photo copy) 
back issues as sets, so you could get 
bound sets and fill in the gaps (if you 
have any). 

It seems that CP/M is alive and well in 
England. I recently received a letter from 
a person still making and selling CP/M 
systems. The Amstrad appears to be very 
popular as well (something like 500, 000 
strong). As to your graphics boardlcan 
only hope someone reads this and send 
us the articles you need. The idea of 
using classic systems for terminals is not 
new, but certainly a great use. Maybe I 
need tofmdsome articles about turning 
Kaypros into X-Terminals or ANSI com- 
patible (MSDOS ANSI.SYS) terminals 
With all the increase interest in UNIX, 
classic systems as terminals might be 
very cost effective. 

Thanks again for the list of possible 
users, and keep up the good work in 
spreading TCJ's name around Europe. 
BDK. 



Sept. 23, 1992 

Dear Bill 

1 am enclosing my check for $20.00. 
This is in part a donation to support TCJ 
and for issue 56 which I have not re- 
ceived. Please send me a copy of issue 
#56. 1 don't understand the post office 
not forwarding TCJ since they forwarded 



everything else. Any way I don't want to 
miss an issue. 

I have been an avid reader of TCJ since 
1 met Art Carlson at the SOG in Bend 
many years ago. 1 started subscribing 
with issue 16, and have perused every 
issue since. The mix of articles has been 
great. I like both hardware and software 
subjects. Al Hawley's series on assembly 
language have been great. Jay Sage's 
have been near the top of my list. 

What 1 have liked especially about TCJ 
is that in addition to articles 1 can under- 
stand there are articles that stimulate my 
though and interest. TCJ is essentially 
the only serious journal that is keeping 
alive CP/M, and 8 bit computing. Your 
idea of responding to the novice as well 
as advanced hobbyist is great. Please 
keep up the good work. 

Yours sincerely, A. A. Straumfjord, 
Camp Sherman, Oregon. 

PS. I personally would find TCJ worth 
$50 or $ 100/yr but I fear many subscrib- 
ers could not afford that. 

Thanks for the extra money Al. 

The last few months have been a big 
money drain for me personally. TCJ 
hasn 'tpaid it 's own way for a long time. 
I'll put some of your donation toward 
the increase in rates coming up next 
year. I have figured out it cost me about 
$2. 75 to get an issue to you. So our 
problems with the post office was just 
too much. I tried sending make up issues 
out, but discovered I had spent almost 
an extra $100 doing that. I have had a 
talk with the post office and am sending 
TCJ with a minor change which should 
eliminate (or at least cut down ) on in- 
correctly handled issues. 

Well if you met Art at a SOG, you most 
likely saw me as well. I went to all the 
SOGs but the first one. I also helped Art 
man a table more than once. I really 
miss having SOG like meetings, so we 
are starting to consider having one in 
Sacramento next summer. Charles 
Stafford our Kaypro person has had sev- 
eral here already and wants to try and 
go national. With the Trenton computer 
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feast in New Jersey, only seems natural 
to have one on the west coast to match. 
I believe that 30% of my subscribers are 
from California. It may be hard getting 
your favorite writers out here, but we 
will try. I know they like seeing and 
hearing from their fans. 

Thanks again, from Bill Kibler. 

Oct. 3, 1992 

Dear Bill, 

I apologize for taking so long to reply to 
you. I,m terrible about writing letters. 
Articles I can whip up in a hurry, but 
letters... 

I'm quite pleased with your new format. 
You probably share the kind of frustra- 
tion 1 have felt with ASICs, since you 
specifically say none of those in articles. 
Thank you. 

I have a little difficulty writing elemen- 
tary level articles. The biggest problem 
is that no steering is possible. I often do 
classes in beginning LANS and in those 
I can adapt as 1 go. 

There is really little difference between 
a Stat mux and a LAN. That's usually 
the approach 1 take in trying to explain 
how a LAN works. I prefer not to con- 
fuse the issues of media versus access 
method. In effect, a multi-user computer 
becomes a degenerate LAN or in some 
cases a "LAN in a can". 

As far as Netbios, leave me out. Most of 
the bad experiences 1 alluded to in my 
articles have been from PC networks. 
Personally 1 never thought any PC ever 
belonged on a LAN, although the BSD 
for PC might finally make it. Usually I 
tell people to get a workstation or some 
other capable machine and put two in- 
terfaces in it so that all the PC's can be 
isolated on their own segment without 
causing grief for everybody. 

As far as network checkers, we make use 
of Netwatch quite a bit. It's freely avail- 
able. There are some packages that are 
even better, but some of them have so 
much information that you can't read 
the display from a distance. Netwatch 



just scrolls the header of possible pack- 
ets on the screen. 

By the way, do you have Internet access? 
It was very convenient for me to be able 
to email my stuff to Jay Sage. 

Wayne Sung 

/ loved getting your hand written letter 
Wayne. I am a lot like you when it comes 
to letters and articles. That is one rea- 
son I often hand write responses (only 
use computer for articles not letters), as 
well as being so much faster and per- 
sonal. Please don 't feel you can 't 
' 'steer ' ' our readers like you do your 
classes I know what you mean about 
getting students to look over material 
and concepts by just prodding them in 
the right direction. However I find the 
students ' 'steering ' ' me more often than 
not It is all those funny questions that 
make you think they just woke up that 
minute in your class even though you 
have been looking them straight in the 
face during the last hour of lecture. My 
advice to all my writers has been to 
think you are teaching a class and talk- 
ing to students not readers. Maybe just 
tape recording your class and reprint- 
ing the questions and answers would 
make some great articles. 

Novell 's Netbios has been nothing but 
problems again. We thought we had the 
problem fixed only to find it back again 
last month. Yes my opinion about net- 
works is changing but I am not burned 
out on them yet (soon however I am 
sure). I think you are a little overworked 
like most of the writers right now. The 
economy has everybody doing double 
duty and some like me doing triple duty. 

I have looked for Netwatch but yet to 
find it. I will keep looking. How about an 
article on what and why of checking 
network data by using Netwatch? I know 
my students can 't wait to learn about 
trouble shooting LANs On ASICs, it 
really is PALs, they just burn out too 
often for my taste. Then when they do 
bum out, often the whole system be- 
comes junk when the supplier is gone 
and you have no replacements for the 
part. The official stand at TCJ is do it 
first in TIL chips, then show the differ- 



ence or alternate PAL option. Or in short 
give us choices and alternatives. 

Lastly I am trying to get on Internet I 
have joined CompuServe to access their 
Internet link, and now it seems GENIE 
has started doing Internet as well (which 
I already belong to.) With so many things 
to get up to speed on, Internet is really 
a back burner option at the moment. I 
hope to be using it some time after the 
first of the year. Thanks again for all 
you have done for TCJ. Bill Kibler. 



10-17-92 

Dear Mr. Kibler, 

I've just received issue #57 of TCJ, with 
my article "Shell Sort in Forth". My only 
lament is that a shaky Undo Key appar- 
ently introduced a series of characters 
into a line of code in screen #7. The line 
between BEGIN and WHILE should be 

DUP GAP @ - DUP 0< NOT SWAP 

S@ SV @ > AND 

as in screen #13. Ah well, fast comput- 
ers only make for faster mistakes! 

Yours truly, Walter J. Rottenkolber 

Thanks for the correction Walter. Your 
article fit in perfectly with the introduc- 
tion to Forth. Not only was I able to give 
our readers a good how to get started, 
but also a great application in the same 
issue. I try to get supporting articles as 
much as possible, but that option is based 
more on what our writers give me and 
less on what I would like to see. 

Our readers will be looking forward to 
one of your next articles. You have men- 
tioned doing some more applications 
(game of LIFE, and Interrupt handling) 
which I am sure will go over very well. 
Your idea however of showing how to 
debug Forth code, especially after the 
typo above, is proably something our 
readers could use now. Learning to de- 
bug what you have written is always 
such a big hurdle for beginners to mas- 
ter. Thanks for all your support of TCJ. 
Bill Kibler. 
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The Z-System Corner 

By Jay Sage 



Regular Feature 

ZCPR Support 

Language Independence 



In my last column I described a new idea 
for allowing message text in programs 
to be changed easily for adaption to vari- 
ous languages, or even just to suit a 
user's preferences. I would like to con- 
tinue that theme this time as well. 

First, in the process of working on the 
new 2nLER version 1.1, which includes 
the language overlay implementation, I 
thought of a couple of additional points. 
Second, Al Hawley sent me some very 
interesting comments, and he built on 
my ideas for use in the new version of 
BYE that he is writing. [BYE is the 
resident program that is used to imple- 
ment what is called a "remote access 
system", a computer system that can be 
operated by a remote user via modem or 
direct connection to a serial port.] 

An Addition to the Module Header 

In the version of the text message (i.e., 
Z3TXT) module I finally arrived at by 
the end of the last column, there were 
several items included in a header at the 
beginning of the module. First, there 
was an opcode of "RST 0", which, if 
executed, would result in a warm boot. 
A file containing a Z3TXT module 
should never be executed, but at a cost of 
one byte we could protect ourself against 
that outside chance. 

The header also contained the string of 
characters "Z3TXT' ' followed by a null 
(0) byte. Many Z-System modules in- 
clude such identifiers. In this category 
are resident command packages (RCPs), 
flow command packages (FCPs), and 
environment descriptor modules 
(Z3ENVs). Programs, such as Bridger 
Mitchell's excellent JETLDR.COM, that 
load these modules from files into 
memory can use the ID string to validate 



the file, that is, to make sure that it is the 
kind of module that the user has stated 
it to be. User mistakes and damaged 
files can thus be detected. Some mod- 
ules, however, such as named directory 
registers (NDRs) and terminal capabil- 
ity descriptors (Z3Ts), do not have such 
ID strings; they probably should have. 

The next header item I included was the 
name of the program for which the 
Z3TXT file contains message texl. Load- 
ing a text overlay intended for one pro- 
gram into a different program would 
probably not produce very safisfactory 
results <grin>. By including the pro- 
gram name in the header, a loader utiUty 
- the equivalent of JETLDR ~ would be 
able to catch such an error. Even if it 
didn't outright refuse to load the mod- 
ule, it could at least point out the pos- 
sible problem to the user and ask for 
confirmation of the command. 

The last item in the header I proposed 
was a three-letter language identifier. 
This would ensure proper identification 
of the language contained in an overlay 
module. This could help a user who 
could not otherwise identify the language 
with certainly, and it might also be of 
use to a loader utilit>'. 

There was one very important item that 
I omitted: the size of the module. If the 
loader cannot determine how much space 
has been allocated for the text module, it 
might end up installing a module that 
was too large. This would probably re- 
sult in some executable code being over- 
written. Again, the user would probably 
be quite disappointed by the results ! This 
happened to me while I was working on 
ZFILER. I don't know if Al Hawley 
suffered any such accidents or whether 
he was just smart, but his list of sugges- 



tions to me included such an item for the 
header. The header, thus, now stands as 
follows: 

rst 

db 'Z3T,\T',0 ; null-terminated ID 

; 12345678 ; must be 8 characters, 

db 'PROGNAME' ; pad with spaces 

; 123 ; must be 3 characters 

db 'ENG' ; name of language 

dw LENGTH ; length of module 

The use of this length byte is somewhat 
tricky. When the program code is as- 
sembled, the messages for some language 
have to be included directly in the source 
code. In that case, the length word should 
contain the amount of space allocated in 
the program for the text overlay, not the 
amount of space actually used. It would 
probably be defined using an EQU di- 
rective in the source code. 

On the other hand, when modules are 
assembled as independent overlays, the 
length word should contain the actual 
length of the module. Then, when the 
loader utility attempts to load a language 
overlay into a program's COM file, it 
could compare the length word in the 
overlay to the length word in the COM 
file to make sure that the new overlay 
will fit properly. 

Here is the trickiest part. The loader 
must remember the original value of the 
length from the COM file and reinstall 
that value after the new language over- 
lay has been installed. In other words, 
the length word in the header serves two 
distinct purposes: in a free-standing over- 
lay file it represents the space needed for 
the module; once installed into a COM 
file it represents the space available for 
the module. 
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New Data in the Text Module 

In my examples last time, the Z3TXT 
module contained only null-terminated 
text strings. While working on the text 
module for ZFILER, I realized that one 
might wish to include some other types 
of data. Al Hawley also showed me an 
additional way to handle the address table 
and data. I will now describe both of 
these extensions. 

In ZFILER, as in many other programs, 
users are occasionally prompted with a 
question that requires a yes or no an- 
swer. In the past, the answer has been 
given by pressing either the " Y" key or 
the "N" key. This is all well and good 
for English speakers, but other languages 
may use different words represented by 
different letters. (Interestingly enough, 
though the word for "no" varies, the 
first letter is nearly universally "N" for 
European languages; "Y", on the other 
hand, will often not fit the bill.) 

I wanted to fix this in ZFILER, so I 
decided to put the two letters represent- 
ing an affirmative and a negative answer 
into the text overlay and to have the code 
compare the user's response to the vari- 
able characters stored there. Recall the 
complete structure of the module as I 
proposed it last time. Between the header 
and the actual message strings was a 
table of address offsets to the text strings. 
The appearance was thus as follows: 

z3txt: ; start of module 

; header goes here (see above) 

; table of address offsets 

msgl: dw .msgl - z3txt 

msg2: dw .msg2 - z3txt 

; actual message strings 



Since the length of the "yes" and "no" 
characters is fixed, namely one charac- 
ter, there is no need to use indirect ad- 
dressing as with the variable-length 
message strings. The letters can be put 
directly into the address-offset table. It 
might then have the following appear- 
ance: 

; table of address offsets and 
; ..fixed-length data 
affirm: db 'Y' 



negate: 


db 


'N' 


tnsgl: 


dw 


.msgl - z3txt 


msg2: 


dw 


.msg2 - z3txt 



In Al Hawley' s new version of BYE for 
Z-Systems (called NZBYE) there are 
places where one wants the code to 
modify a string dynamically. For ex- 
ample, there might be a message of the 
form, ' 'You have 7 minutes remaining, ' ' 
This message might be displayed each 
minute once the user has fewer than 10 
minutes of allowed access remaining for 
the current call. Here is how Al sets up 
the module. 

; table of address offsets 
timmsg: dw .timmsg - z3txt 
timval: dw .timval - z3txt 
msg2: dw .msg2 - z3txt 

; actual message strings 
db ' minutes remaining' ,cr,lf,0 



The table values stored at the addresses 
labeled "timmsg" and "msg2" point to 
the beginnings of complete message 
strings (at addresses ".timmsg" and 
".msg2"). Those messages would be 
displayed as I described last time using 
a special string-printing subroutine. In 
Al's extension, the address at label 
"timval" would be used differently. A 
fixed-length character string would be 
computed by the program and written 
into the space at label ".timval", whose 
address would be computed from the 
table entry at ' 'timval" . A slightly more 
elaborate version of such a subroutine is 
presented later in this column. 

Alexander Schmid and I faced a similar 
problem in ZFILER but handled it dif- 
ferently. We broke the strings into sepa- 
rate pieces. Sticking with the above 
example, we would have: 

; table of address offsets 
timmsg: dw .timmsg - z3txt 

timmsg2: dw .timmsg2 - z3txt 

msg2: dw .msg2 - z3txt 

; actual message strings 



In the program code, the two pieces of 



the message would be printed separately, 
each by a call to the message-printing 
subroutine. The time value would be 
sent to the terminal in between those two 
calls. It is not clear to me which method 
is best. The second approach has an 
extra null byte at the end of the first 
message string, and the display subrou- 
tine has to be called an extra time. On 
the other hand, with Al's method, the 
address has to be calculated and the 
computed value has to be stored into the 
message string instead of just sending it 
directly to the screen. My feeling is that 
the two methods are so nearly equal in 
efficiency that the choice should be made 
based on one's programming style pref- 
erence. 

Some Additional Points 

Al Hawley was still not completely sat- 
isfied with the storage efficiently in the 
text module. Remember that last time 
we began with an approach in which 
each individual message started at a fixed 
address, with extra space included with 
each one to allow for longer messages in 
another language. Then we added the 
address-offset table ~ with all entries in 
fixed locations ~ so that the messages 
could be of different lengths without 
having to waste expansion space for each 
one. 

With this approach, however, one still 
has to allocate some overall extra space 
in case the complete collection of mes- 
sages in another language is longer. 
Consequently, space is wasted in the 
COM file when a shorter language over- 
lay is loaded. This bothered Al. 

I had thought about this, too, and had 
concluded that there really was nothing 
one could reasonably do about it. If the 
Z3TXT module could be placed at the 
end of the COM file, then its length 
could be variable. However, programs 
generally store data after the end of the 
material stored in the COM file. If the 
Z3TXT module were appended, then the 
code would have to provide indirect ad- 
dressing for all data references, with the 
addresses depending on the length of the 
curtently loaded Z3TXT module. 

This approach would also cause prob- 
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lems with type-4 programs. These are 
programs whose load-address is deter- 
mined at run-time by the ZCPR34 com- 
mand processor. Generally, type-4 pro- 
grams are loaded as high as possible in 
memory. This requires knowing how 
much memory the program uses. Vari- 
able-length text overlays stuck on the 
end of the COM file would greatly com- 
plicate this situation. 

Al Hawley's thinking on the subject was 
colored by the task he was tackling. BYE 
is not a transient (temporary) program. 
The COM file (BYE.COM) causes a 
block of code called a resident system 
extension (RSX) to be installed semi- 
permanently at the top of memory under 
the normal CP/M operating system code. 
There it intercepts operating system calls, 
changing existing functions and adding 
new ones. Because it is resident, BYE 
reduces the memory space available to 
all other programs. Therefore, it is of 
great importance to keep the code as 
short as possible. To accomplish this 
with NZBYE, Al came up with a very 
clever idea that I will describe in just a 
moment. 

First I want to mention one other new 
consideration that arose in connection 
with NZBYE. Remember that BYE's 
fiinction is to make the modem port an 
extension of the system's console (key- 
board and screen) so that the computer 
can be operated either by the local opera- 
tor (the sysop) or a remote caller. 

Picture Al sitting at the console of his 
Ladera Z-Node in Los Angeles while a 
caller from France is on-line. Being an 
accommodating person, Al would like 
user messages sent out by BYE to appear 
in French. On the other hand, there are 
some messages generated by BYE that 
are for the sysop only and appear only on 
the local screen. These should be in 
English for Al. For Helmut Jungkunz in 
Germany, however, they should be in 
German, even when the French caller is 
using the system. 

Well, the conclusion Al came to was that 
NZBYE needed to break the messages 
into two groups: local messages and re- 
mote messages. (The remote messages 
go to the local console as well. Ideally, 



these messages would be provided in 
two languages and separate versions 
would be sent to the local and remote 
consoles. However, this would waste 
memory by complicating the code and 
increasing the space taken up by the 
message text.) 

Since each user of BYE has to assemble 
the program anyway (because of the 
choice of various options and system 
characteristics), there is no reason not to 
assemble in the message text as well. To 
make it easy to change the messages, Al 
has gathered them into one place and 
put their code in a separate LIB file. 
Those messages do not have to be ad- 
dressed via an address-offset table; they 
can be addressed directly. Conditional 
assembly pseudo-ops can be included so 
that when certain optional functions are 
omitted from the BYE code, the corre- 
sponding messages can be omitted as 
well. 

The remote messages have to be loaded 
dynamically depending on the caller. 
They could be handled as we have de- 
scribed for standard programs, but then 
one would have to pre-allocate enough 
space to accommodate the longest set of 
messages for all supported languages. 
Al conceived the following approach. 

The remote message text is not stored in 
BYE at all; it is stored in a separate RSX 
that is loaded after (underneath) BYE. 
As a result, its size can vary. Here is a 
more detailed description of what hap- 
pens. When BYE.COM is run, it has to 
deal with two tasks. As before, it has to 
make sure that the BYE RSX is loaded, 
installing it in upper memory if it is not 
already present. Then it has to make 
sure that the correct language RSX is 
loaded. If BYE.COM has just loaded 
the BYE RSX, then it has to load the 
required language module, too. If BYE 
was already present in memory, then 
BYE.COM has to remove the old lan- 
guage RSX and then install the one now 
required. (It could try to determine if the 
right one is already installed, but it may 
be easier to just dump the old one and 
start over.) 

There is now one new complication. 
With our Z3TXT modules, the main code 



does not know where the actual message 
strings are stored, but it does know where 
the address-offset table is stored. This 
may not be the case with the BYE.RSX. 
We could change the structure of the 
language RSX, placing the address off- 
set table at the end of the module. This 
would be a fixed address relative to the 
BYE RSX code, and the address could 
be adjusted just as all other addresses are 
adjusted when a relocatable module, such 
as an RSX, is loaded. However, one 
would like to maintain compatibility and 
minimize the proliferation of standards. 

In order to use the same module struc- 
ture, Al added an extra level of address 
indirection. Since BYE.COM handles 
the installation of both RSXs, it has the 
global picture and can provide the BYE 
RSX with the address at which the lan- 
guage RSX begins. This address is loaded 
into a specific data word in the BYE 
RSX. Here is what Al's double-indirec- 
tion implementation looks hke. 

Suppose the language RSX is to contain 
the messages ' ' msg 1 ' ' and " msg2 " that 
we showed in the earlier examples. An 
RSX contains some additional header 
code for intercepting operating system 
calls, for protecting itself (so it does not 
get removed during warm boots), for 
identifying itself, and for removing itself 
from memory. The remainder of the 
RSX will look just like the Z3TXT mod- 
ules used for other programs. The start- 
ing address of that code ("zStxt") is 
what BYE.COM will store at, say, the 
label "byerem" in the BYE RSX code. 

Al uses a subroutine to compute the real 
addresses of the messages through two 
levels of indirection. This sounds more 
complicated than it really is; I hope you 
will try to follow it. When the routine is 
called, the HL register pair has been set 
to the relative position (or offset) in the 
Z3TXT address-offset table for the de- 
sired message (or other data structure). 
For example, in the case of the first 
message, this value would be (msgl- 
z3txt). Although the individual values 
of "msgl" and "z3txt" will vary de- 
pending on where the language RSX is 
loaded in memory, the difference is a 
constant that is known at the time BYE 
is assembled. Since ' ' msg 1 " is the first 
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message in the table, the value would be 
20 (the length of the Z3TXT module 
header). The second message would 
have the value 22, and so on. 

Here is the complete code for Al's sub- 
routine, called GETM2. The value of 
the offset to the offset in HL is converted 
into the absolute address of the specified 
object and returned in HL. Otherwise, 
only register A is altered; if one desired, 
register pair AF could be protected on 
the stack as is done with DE. 



push de ; save DE on stac 

Id de,(byereni) ; address of z3txt 

; first indirection: get absolute address where 
; offset to message text is stored and load the 
; value into HL. 
add hl,de ; real address of offset 

Id a,(hl) ; get low byte into A 

inc hi ; point to high byte 

Id h,(hl) ; get high byte into H 

Id l,a ; get low byte into L 

; second indirection: given offset in HL, calculate 
; actual address of the message text in Z3TXT 
module, 
add hl,de 

pop de ; restore DE 

Plans for Future Columns 



In two issues, TCJ will be marking its 
10th aimiversary. At the request of the 
editor, for that issue I will be revisiting 
the topic of getting Z-System running on 
a computer that is currently running a 
form of standard CP/M. The column 
will be addressed to novices, but there 
might be some tricks and thoughts of 
interest even to veteran Z-System users. 

To learn about the subject myself, I plan 
to dig out one of the many Kaypros 
warehoused in my basement and go 
through the complete process of bring- 
ing up an NZCOM Z-System on it. I 
will also install Z3PLUS on one of my 
CP/M-Plus computers, perhaps the 
Televideo 803, on which 1 currently have 
CP/M-2.2 and NZCOM but for which I 
believe I have a CP/M-Plus boot disk as 
well. 

For next time I hope to describe some 
advanced uses of the PMATE/ZMATE 
text editor. MATE is generally used 
manually to edit files, but it can also be 
used as a generalized, programmable 
text-processing tool. 1 have installed a 
special permanent macro that greatly 



facilitates this kind of use. 

For example, on my 486/33 PC at work 
I have been running many long series of 
automated simulations of electronic cir- 
cuits using PSPICE. A 4D0S batch file 
starts the process by writing out a file 
with the circuit parameters (for example, 
capacitor values, voltage levels, clock 
rise and fall times). It then invokes 
PSPICE and feeds the output file to 
PMATE, which uses a macro to analyze 
the data and determine whether or not 
the circuit operated as desired. This 
macro is stored in a separate file (or 
files, if there are subroutine macros). 
The resuhs of the evaluation are written 
out in files that are then read by the 
4D0S batch file and used to generate the 
next set of simulation parameters. In 
this way, I can leave the computer run- 
ning unattended for days or even weeks, 
and when I come back there is a nice 
report awaiting me with a summary of 
the results. Readers may be able to think 
of many uses for this approach. 

Language Independence is a big prob- 
lem. While checking on new versions of 
Novell's Netlite, I discover d they have a 
separate version for each language. It 
solved the problem but at a price in 
programming time and stocking differ- 
ent versions. Jay's ideas sure make more 
sense and like Al Hawley's concept of 
needing different languages for differ- 
ent sections. From a maintenance stand 
point, by having different modules you 
could load them on the fly, that would 
allow english speaking support people 
to work at a site that normally uses an- 
other language. 

I am sure there are many other options 
to this problem. If you have one, or 
found some "slick" way of enhancing 
Jay's work, let Jay know. 

Contact Jay on GENIE as JAY.SAGE 
or see his add on the inside cover for 
other options. BDK. 



In Issue #59 

- Programming the 6526 Com- 
munications Adapter. This in- 
depth article shows how to ap- 
proach and program the adapter 
in BASIC. A great review and 
startup articles for those wanting 
to learn the insides of a com- 
puter. 

- D/A Conversion on the Cheap. 
This is part two of a series on 
how to generate analog signals 
using a few resisters and an op- 
amp. Programming support us- 
ing Forth and any parallel port 
makes this one of our platform 
independent projects. 

- Real Computing tackles losing 
the "Superblock" on a MTNIX disk 
system. 

- Z-System covers PMATE, one 
of Jay's favorite programs. 

- More articles on S-100 and 
Kaypros as well. 

Support Requests 

To request support or assistance 
on a given project, please write 
our support people directly. TCTs 
Technical Editors place their 
address in their columns so that 
you can get faster response by 
writing to them directly. Your 
requests will be included in later 
articles. Our editors reserve the 
right to refiise service or redirect 
you to a more appropriate source. 
Please include as much back- 
ground information as possible. 

Contacting TCJ 

Mail: 

TCJ 

P.O. Box 535 

Lincoln, CA 95648 

On GENIE: 
B.Kibler 
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Real Computing 

By Rick Rodman 



32-Bit Systems 

All Readers 

MINIX, UZI and GNU 



Minix, Uzi, Gnu - and lessons from 
home movies 

Minix goings-on 

Many Minix OS hobbyists have changed 
over to Linux, for two reasons: first, 
there are no restrictions to worry about, 
and second, Linus Torvalds, the author, 
is in favor of it becoming a big, complex 
operating system. 

The Minix community has been revi- 
tahzed by a sudden new burst of acti\ity, 
however. A gentleman named Frans 
Meulenbroeks proposed that the Minix 
kernel be rewritten as a clean 
microkernel design. As Andy 
Tanenbaum pointed out with respect to 
Linux, the microkernel type of OS de- 
sign has been almost universally ac- 
claimed as superior, and most new oper- 
ating systems use that design. While 
Minix started out as a microkernel, the 
severe design constraints of the Intel 8086 
architecture compromised it to the point 
that most advantages of a microkernel 
were lost. The new design discussion 
has basically centered around building 
a true microkernel design while still 
retaining as much as possible of Minix. 

In a true microkernel, the protected ker- 
nel of the operating system does task 
switching and message passing only. 
Device drivers and other service tasks 
run as user-level tasks. 

Frans introduced his proposals in an essay 
entitled "Proposal to restructure 
MINIX". Here are a few excerpts. 

' 'Minix as it is now is quite cumbersome 
if you want to add new tasks. You have 
to change NR_TASKS, table.c, add the 
new task, recompile fs/mm/kemel/tools 



(they all depend on the include file which 
defines NRTASKS). Quite a job. 

' 'This way it is quite complicated to add/ 
remove drivers. Furthermore it is dif- 
ficult to understand how the system 
works. 

"My idea is to restructure the kernel 
into a number of different processes. 
Each process corresponds with a kernel 
task (e.g. the floppy driver). None of 
them accesses variables from other task 
(low coupling). 

"To support this, there is a microkernel 
(fiirther on called core, to avoid confii- 
sion with the current kernel) mainly 
consisting of system.c and proc.c (and 
perhaps a part of maiac). 

"This core should have the following 
functions: 

- context switching 

- message passing 

- basic clock handling 

• memory copying between tasks 

- support for interrupt handling 

- creation and removal of processes. 

"Functions supplied by the core itself 
are: 

- the fiinctions from system.c and proc.c 

- install interrupt handler 

- deinstall interrupt handler 

- attach to major device number (this 
way device numbers can be connected 
to drivers). This can simply be the map- 
ping of the device number to the task id. 

"If we identify tasks by a bit in their 
proc struct and make them standalone, it 
is very easy to add a new task to the 
system or remove one. Of course only 
the super user can do so (by means of a 



new system call). An implementation of 
this could be done stepwise by: 

- introducing task and driver bits in the 
proc struct, perhaps also a bit must be 
reserved to identify the idle task. 

- rewrite the macros in proc.h to use 
these driver bits instead of the 
NR_TASKS. 

- rewrite the code which uses things like 
ENDTASKADDR. 

- allow message passing between all 
drivers. 

- take a simple driver and rewrite it so 
that it is stand alone compilable (so it 
uses the syscopy system call instead of 
directly calling phys_copy and umap). 
The printer or the memory task seems 
a good candidate for this. 

- add a way to attach/detach an interrupt 
routine to an interrupt source 

- add a way to attach/detach to a major 
device number 

- add a system call which lets a program 
start as task or server. 

- remove the rewritten driver from the 
system and start it using the new system 
call 

- add code to the build process to load 
standalone drivers on boot time 

- rework the other drivers, taking them 
out of the kernel one at a time 

- clean up the remaining kernel (which 
should mainly be system.c proc.c and 
some hulp [sic] code)." 

There have been many related discus- 
sions on Minix' message system, which 
is quite cumbersome due to the six mes- 
sage formats. Some have suggested us- 
ing variable-length messages. Of inter- 
est is the intent to keep Minix' size small 
and manageable - in fact, to make its 
kernel even smaller and simpler than it 
is today. Even Andy Tanenbaum, the 
author of Minix, contributed to the dis- 
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cussion in a positive way. While Minix 
1.6 will be released soon as an incre- 
mental improvement over 1.5, it's good 
to see that the community has rediscov- 
ered a technical vision for Minix' future 
- a simple but extensible operating sys- 
tem that can be completely understood 
and extended in meaningfiil ways by a 
single individual. 

Recently published on Usenet was a syn- 
tax guide for the PC MINIX assembler. 
This assembler doesn't follow the ar- 
cane and stultified "structure" conven- 
tions of Intel's and Microsoft's assem- 
blers. Nor does it follow the more nor- 
mal but still quirky conventions of the 
CP/M-86 assembler. Instead, it follows 
thoseof IBM'sPC/lX assembler. "Aha! 
Of course! ' ' 1 hear you all saying. Well, 
for those of you who have been on the 
other side of the planet from such earth- 
shaking products as PC/IX (like me) and 
don't know that syntax like the back of 
your hand, send me a quick note and I'll 
send you a copy. It's too lengthy to print 
in this column. 

Uzi 

Another free operating system is Uzi, 
developed by Doug Braun for the Z-80 
processor. Written in C, it is a fairly 
complete Unix Version 7 clone - in a 
little over 6,000 lines of code. Although 
it's a monolithic kernel design, it's pretty 
small. It takes 32K bytes of RAM for the 
kernel itself on the Z-80. I've been 
thinking about porting it to the NS32 
processor - and putting it in PROM. 

Gnu tools under OS/2 

GCC, the Gnu C Compiler, and G-Plus, 
the Gnu C++ translator, have been ported 
to OS/2 2.0. Some folks have been using 
them for code development. This is a 
rocky road to travel down, but the prod- 
uct is free (at least if you have ftp ac- 
cess). Interestingly, the 32-bit linker 
(LINK386) and the Resource Compiler 
(RC) are supplied with the operating 
system, so all you need is the compiler 
itself I don't have copies of this soft- 
ware yet, but I'm looking to acquire 
them shortly. Other Gnu tools, such as 
Gawk (Gnu AWK), Bison, and Gnu 



Emacs are being ported and will be 
available shortly. 

I mentioned last time that IBM presently 
offers only C for OS/2 2.0. There are 
other compilers which can generate 32- 
bit code for the system, notably Watcom 
C, Microway's Fortran, and Logitech 
Modula-2. IBM also provides a strange 
programming environment which works 
with C, called System Object Model 
(SOM). It's heavily into object-oriented 
mumbo-jumbo. In response to much 
hue and cry, IBM has promised to re- 
lease a C++ compiler "soon". Person- 
ally, I don't care. C lets me do what I 
need to do. 

Programming is the art of effectively 
expressing algorithms in a form com- 
prehensible to both machines and hu- 
mans. That language which does so most 
efficiently for a specific class of prob- 
lems is the best for that class. In my 
investigations so far, object-oriented pro- 
gramming languages I've looked at have 
failed to either generate efficient code or 
express algorithms clearly. The indus- 
try will probably never make a transition 
to OOP, but OOP may be more than a 
fad nonetheless; it may be an incremen- 
tal step to the next technology. 

Remember home movies? 

You know. Super 8 and Standard 8? 
They were big once. They had full color, 
slow-motion, sound, and zoom. What 
happened to it all? It disappeared over- 
night. Video equipment blew it away - 
even faster than the video proponents 
themselves expected. 

OK, in retrospect, we can say that the 
technology was lousy. You only got 
about 3-1/2 minutes per roll of film. You 
had to wait for it to be developed. Espe- 
cially with Standard-8, you could mess 
up and lose the whole roll trying to un- 
load the film. 

The lesson we learn from the rapid de- 
mise of home movies is that people will 
dump a technology almost instantly when 
something better comes along - espe- 



cially one that addresses their long-ig- 
nored frustrations and problems. 

In TCJ #57, 1 discussed some technology 
fads I expect real soon. Some folks have 
pointed out that I forgot to mention still 
video. Still photography has terrible tech- 
nology problems - the same ones as 
home movies, in fact, I've mentioned 
losing whole rolls of film due to camera 
jams, for example, to other photogra- 
phers, and been surprised to hear that 
even professional photographers have 
these problems. Besides, the insurance 
industry is adopting still video like mad. 
With a video digitizer boards, the photos 
can be centrally stored on computers and 
made available via LANs. 

Based on the lessons learned from the 
home movie to VCR transition, some 
have predicted that still video will com- 
pletely eradicate film even while the cost 
is higher. 

Personally, I don't think so. The cost is 
still way too high for the full suite of 
necessary equipment - don't forget, 
you've got to include printing hardware. 
Also, the resolution still isn't too good. 
The day when Hasselblads sit unsold on 
flea-market tables at giveaway prices is 
still a couple of years off. 

Nevertheless, this may be the best time 
for technical folks to familiarize them- 
selves with the technology. With indus- 
try and government moving away from 
film so rapidly, there will be lots of 
opportunities in file conversion, view- 
ing/cataloging software, and suchhke. 
One nice thing coming out of the imag- 
ing technology drive is the move to SCSI 
as a standard I/O interface. Most high- 
end color printers, for example, have 
SCSI interfaces, as do most of the new 
scanners coming out. 

Next time 

Push the edge of the envelope with us as 
we try to fix corrupted Minix filesystems, 
using only our bare hands, the ROM 
monitor, and RDMINIX tools under 
DOS. Where else but in computers 
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would something so fragile be called a 
"superblock"? 

Where to call or write: 

BBS or Fax: 1-703-330-9049 (There's 
an autoswitch feature in the fax ma- 
chine; strange though this seems, it 
appears to work just fine.) 



Here is a brief synopis of the MINIX assembly language. It is the 
same as IBM's PC/IX assembler. 

2. TOKENS 

2.1 Numbers 
Same as C 

2.2 Character Constants 
Same as C, supporting \n, \t, \b, \r & \f 

2.3 Strings 
Same as C 



2.4 Symbols 

May contain any letter, digit,".", "- 

a digit or "~" as the first characta. 



' or "_", but cannot have 



All global names have 8 significant characters 

The names of the 8086 registers are reserved ((abcdUxlh), [cdes]s, 
[ds)i, [sp]p, bxjdsji & bp Jds]i). The last tvio forms indicate 
register pairs; these names are used in the "base + index' ' 
addressing mode (section 6.1). 

Names of instructions and pseudo-ops are not reserved. 
Alphabetic characters in opcodes and pseudo-ops must be in 
lower case. 

2.5 Separators 

Commas, blanks, and tabs are separators and can be interspersed 
fieely between tokens, but not within tokens (except string and 
character constants) or between the tokens of an expression. 
Commas are only legal between operands. 

2.6 Comments 

The command character is "I". 

2.7 Opcodes 
Listed below. 
Notes; 

1) Different names for the same inshuction are separated by "/" . 

2) Brackets ((]) indicate that or 1 of the enclosed characters can 
be included. 

3) Curly braces (()) work similarly, except that one of the 
enclosed characters must be included. 



2.7.1 



Data Transfer 



2.7.1.1 General Purpose 

mov[b] dest, source | Move word/byte 

mov{bw) dest, source | Move word/byte from source to dest 

pop dest I Pop stack 

push source | Push stack 

xchg opl,op2 I Exchange word/byte 
xlat I Translate 

2.7.1.2 Input/Output 

in[w] source ] Input from source I/O port 

in[w] 1 Input from DX I/O port 

out[w] dest I Output to dest 1/0 port 

out[w) I Output to DX 1/0 port 



2.7.1.3 


Address Ob 


iect 


Ids 


reg,source 


1 Load reg and DS from source 


les 


reg,source 


1 Load reg and ES from source 


lea 


regjSource 


j Load effect address of source to reg 
landDS 


seg 


reg 


1 Specify seg reigster for next 
1 instruction 


2.7.1.4 


Flag Transfer 


lahf 




] Load AH from flag register 


popf 




1 Pop flags 


pushf 




1 Push flags 


sahf 




1 Store AH in flag register 


2.7.2 


Arithmetic 




2.7.2.1 


Addition 




aaa 




1 Adjust result of BCD addition 


add[bl 


dest,source 


|Add 



adc[bl 

daa 

inc[b] 

2.7.2.2 
aas 
sub[b] 
sbb[b] 
das 
dec[bl 
neg[b] 
cmp[b] 



destjSOurce | Add with cany 

I iDeciinal Adjust ace after addition 
dest I Increment by 1 



Subtraction 

dest,source 
dest.source 

dest 
dest 
dest,source 



cmp{bw} de$t,source 



I Adjust result of BCD subtraction 

I Subtract 

I Subtract with borrow from dest 

i Decimal adjust after subtraction 

I Decrement by one 

I Negate 

I Compare 

I Compare 



2.7,2.3 
aam 

imul[b] source 
mul[b] source 



Multiplication 



2.7.2.4 
aad 
cbw 
cwb 
idiv[b] 
div[bl 

2.7.3 
2.7,3.1 
and[b] 
not[bl 
or[b] 
testfb] 
xor[b] 



Division 



source 
source 



I Adjust result of BCD multiply 
I Signed multiply 
I Unsigned multiply 



I Adjust AX for BCD divison 
I Sign extend AL into AH 
I Sign extend AX into DX 
I Signed divide 
I Unsigned divide 



Bit Manipulation 

Logical 

dest,source | Logical and 

dest I Logical not 

dest,source | Logical inclusive or 

dest,source | Logical test 

dest,source 1 Logical exclusive or 



2.7.3.2 Shift 

sal[b]/shl[bl dest,CL | Shift logical left 

sarfb] dest,CL | Shift arithmetic right 

shr[bl dest,CL | Shift logical right 



2.7.3.3 


Rotate 




rcllb) 


dest,CL 


1 Rotate left, witti carry 


rci[bl 


dest,CL 


1 Rotate right, witfi carry 


rol|b) 


dest,CL 


1 Rotate left 


roi[b| 


dest,CL 


1 Rotate right 



2.7.4 String Manipulation 

The following instmctions address source strings through SI and 
dest string through DI. 

cmp[b] I Compare 

cmp{bw) [Compare 

lod(bw) I Load into AL or AX 

niov[b] I Move 

mov{bw} I Move 

rep I Repeat next instruction until CX=0 

repe/repz 1 Repeat next instruction until CX==0 and ZF=1 

repne/repnz | Repeat next instruction until CX!=0 and ZF^) 

sca{bw) i Compare string element ds:di with AL/AX 

sto{bw} ! Store AL/AX in ds:di 

2.7.5 Control Transfer 

Displacement is indicated by opcode; ' ' jmp' ' generates a 1 6-bit 
displacement, and *'j" generates 8 bits only. The provision for 
"far" labels is described below. 

As accepts a number of special branch opcodes, all of which begin 
with "b". These are meant to overcome the range limitations of 
the conditional branches, which can only reach to targets within - 
126 to +129 bytes of the branch ("near" labels). The special "b" 
instmctions allow the target to be anywhere in the 64K-byte 
address space. If the target is close enough, a simple conditional 
branch is used. Otherwise, the assmebler automatically changes 
the instruction into a conditional branch around a "jmp". 

The English translation of the opcodes should be obvious, with 
the possible exception of the unsigned operations, where ^'lo" 
means "lower'\"hi" means "higher", and "s" means "or 

same". 

The "call", "jmp", and "ret" instructions can be either 
intrsegment or intersegment. The intersegment versions are 
indicated with the suffix "i" . 

2,7.5.1 Unconditional 

br dest jjump^ 16-bit displacement, to dest 

j dest I jump, 8-bit displacement, to dest 

call[i] dest 1 call procedure 

jmpli] dest | jump, 1 6-bit displacement, to dest 

ret[i] I return from procedure 

2 7.5.2 Conditional with 16-bit Displacement 

beq I branch if equal 

bge I branch if greater or equal (s^ed) 

bgt I branch if greater (signed) 

bho I branch if higher (m^igned) 

bhis I branch if higher or same (unsigned) 

ble I branch if less or equal (signed) 



bit i branch if less (signed) 

bio I branch if lower (unseed) 

bios I branch if lower or same (unsigned) 

bne I branch if not equal 

2.7.5.3 Conditional with S-bit Displacement 

ja/jnbe 1 if above/not below or equal (unsigned) 
jae/jnb/jnc | if above or equal/not below/not cany (unsigned) 

jb/jnae/jc j if not above nor equal/below/carry (unsigned) 

jbe/jna i if below or equal/not above (unsigned) 

jg/jnle I if greater/not less nor equal (signed) 

jge/jnl I if greater or equal/not less (signed) 

jl/jnqe | if less/not greater nor equal (signed) 

jle/jgl I if less or equal/not greater (signed) 

je/jz I if equal/zero 

jne/jnz I if not equal/not zero 

jno I if overflow not set 

jo j if overflow set 

jnp/jpo I if parity not set/parity odd 

jp/jpe I if parity set/parity even 

jns lifsignnotset 

js I if sign set 

2.7.5.4 Iteration Control 

jcxz dest I jump if CX = 

loop dest I Decrement CX and jump if CX!=0 
loope/loopz dest | Decrement CX and jump if CX = and ZF = 1 
loopne/loopnz dest |Decrement CX and jump if CX!=0 and ZF=0 



2.7.5.5 Interrupt 

int 
into 

iret 



I Software intermpt 

] InteiTUpt if overflow set 

I Return from interrupt 



2.7.6 Processor Control 

2.7.6.1 Flag Operations 

clc I Clear carry flag 

eld i Clear direction flag 

cli I Clear interrupt enable flag 

cmc I Complement carry flag 

stc I Set cany flag 

std I Set direction flag 

sti I Set intermpt enable flag 

2.7.6.2 External Synchronisation 

esc source ] Put contents of source on data bus 

hit I Halt until interrupt or reset 

lock I Lock bus during next instmction 

wait 1 Wait while TEST line not active 

3.THE LOCATION COUNTER, SEGMENTS AND LABELS 
3 1 Location Counter 

The special symbol " . " is the location counter and its value is the 
address of the first byte if the instmction in which the symbol 
appears and can be used in expressions. 

3.2 Segments 

There are three different segments; text, data and bss. The cunent 
segment is selected usmg the text, data or bss pseudo-ops. Note 
that the " . " symbol refers to the location in the cunent segment. 

3.3 Labels 

There are two types; name and numenc. Name labels consist of a 
name followed by a colon (:). Numeric labeb consist of one or 
more digits followed by a dollar ("$"). Numenc labels are usefiil 
because their definition disappears as soon as a name label is 
encountered; thus numeric labels can be reused as temporary local 
labels, 

4. STATEMENT SYNTAX 
Each line consists of a single statement. 

4.1 Null Statments 

Contam neither an assembler command nor a pseudo-op. May 
contam a label or comment. 

4.2 Instmction Statements 

label: opcode operandi, operand2 | comment 

4.3 Pseudo-op Statements 
An assembler instmction, see below. 

5. EXPRESSIONS 

5. 1 Expression Syntax 

5.2 Expression Semantics 

The following operator can be used: + -•/&!< (shift left) > (shift 
nght) - (unary minus) \ (unary complement). 32 bit integer 
arithmetic is used. Division produces a truncated quotient. 



6 OPERAND SYNTAX 

6, 1 Addressing Modes 

8-bit constant mov 

16- bit constant mov 

direct access ( 1 6 bits) mov 
register mov 

mdex mov 



ax,*2 
ax, #12345 
ax, counter 
ax, si 
ax, (si) 
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index + 8-bit disp. mov 

index + 16-bit disp. mov 

base + index mov 

base + index -t- 8-bit disp- mov 
base + index + 16-bit disp. mov 



ax.*-6(bp) 
ax,#400(bp) 
ax, (bp_si) 
ax, •14(bp_si) 
ax, #-1000(bp_si) 



Any of the constants or symbols may be replacement by 
expressions. Direct access, 16-bit constants and displacements 
may be any type of expression. However, 8-bit constants and 
displacements must be absolute expressions. Floating point 
instnictions that explicity reference the floating point register stack 
do so by specifying stack of&ets: 



&dd 
fitch 



0,3 
2 



I Add fourth to top 

I Exchange second and top elements 



Arithmetic instnictions must have two operands as in the 
example. Other instnictions have only one. Floating point 
arithmetic instnictions that mimic a stack machine can be 
coded with no operands. For example 

fadd 

faddp 1,0 as the same. 

6 2 Call and Jrap 

With the "call" and "jmp" irwtmclions, the operand syntax 
shows whether the call or jump is direct or indirect; indirection is 
indicated with an *'@" before the operand. 

call _routine | Direct, intrasegment 

call @subloc I Indirect, intrasegment 

call @6(bp) I Indirect, intrasegment 

call (bx) j Direct, intrasegment 

call @(bx) I Indirect, intrasegment 

calli @subloc | Indirect, intersegment 

calli cseg, oflfe | Direct, intersegment 

Note that call (bx) is considered direct, though the register isn't 
called, but rather the location whose address is in the register. 
With the indirect version, the register points to a location which 
contains the location of the routine being called. 

7. PSEUDO-OPS 

7.1 Assigment 

Either using the symbol as a label when it is set to "." for the 
current segment with type relocatable. Or via symbol = 
expression when symbol is assigned the value and type of its 
arguments. 

7.2 -long, .word and .byte 

These commands take one or more operands, and for each 
generate a value whose size is a long (4 bytes), word (2 bytes) or a 
byte. 

7.3 .ascii and .asciz 

These commands take one string argument and generate the 
ASCII character codes for the letters in the string, asciz 
automatically terminates the stiTng with a null (0) byte (a C 
shing?). 

7.4 ,2erow 

.zerow take one argument and generates that number of zero 
words 

7.5 .even 

.even generates a null byte is the location counter is odd, thus 
making it even. 

7.6 .text, .data and .bss 

These three commands select the current segment. The assembler 
always begins in the .text segment. No code can be assembled in 
the .bss segment. 

7.7 .globl 

.globl declares that each of its operands, which must be names, aie 
globally visible across all files of the program. The names need 
not be defined in the cunent file, but if they are, their type and 
value arise from that definition independentiy of the globl 
declaration. 

7.8 .comm 

.comm declares storage that can be common to more than one 
module. There are two arguments: a name and an absolute 
expression giving the size in bytes of the area named by the 
symbol. The type of the symbol becomes external. The statement 
can appear in any segment. 
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Since Rick mentioned UZI for the 280, I found it 
on GENIE (in CPM section) and have included 
the introduction section Just so you know exactly 
what it can and can not do. BDK 

UZI: UNIX Z-80 IMPLEMENTATION 
Written by Douglas Braiin 

Introduction: 

UZI is an implementation of the Unix kernel 
written for a Z-80 based computer. It implementts 
almost all of the functionality of the 7th Edition 
Unix kernel. UZI was written to run on one 
specific collection of custom-built hardware, but 
since it can easily have device drivers added to it, 
and it does not use any memory management 
hardware, it should be possible to port it to 
numerous computers that current use the CP/M 
operating system. The source code is written 
mostly in C, and was compiled with The Code 
Works' Q/C compiler. UZI's code was written 
from scratch, and contains no AT&T code, so it is 
not subject to any of AT&T's copyright or 
licensing restrictions. Numerous 7th Edition 
programs have been ported to UZI with little or no 
difficulty, including the complete Bourne shell, ed, 
sed, dc, cpp, etc. 

Howitworl<s: 

Since there is no standard memory management 
hardware on 8080-fainily computers, UZI uses 
"total swapping" to achieve multiprocessing, This 
has two implications: First, UZI requires a 
reasonably fast hard disk. Second, there is no point 
in running a different process while a process is 
waiting for disk I/O. This simplifies the design of 
the block device drivers, since they do not have to 
be interrupt-based. UZI itself occupies the upper 
32K of memory, and the currently running process 
occupies the lower 32K. Since UZI currently 
barely fits in 32K, a fiill 64K of RAM is necessary. 

UZI does need some additional hardware support. 
First, there must be some sort of clock or timer that 
can provide a periodic interrupt. Also, the current 
implementation uses an additional real-time clock 
to get the time for file timestamps, etc. The current 
TTY driver assumes an interrupt-driven keyboard, 
which should exist on most systems. The 
distribution contains code for hard and floppy disk 
drivers, but since these were written for custom 
hardware, they are provided only as templates to 
write new ones. 

How UZI is diflerent than real Unix: 

UZI implements almost all of the 7th Edition 
fiinctionality. All file I/O, directories, mountable 
file systems, user and group IDs, pipes, and 
applicable device I/O are supported. Process 
control (fork(), execve(), signal(), kill(), pause(), 
atarmO, and wait()) are fully supported. The 
number of processes is limited only by the swap 
space available. As mentioned above, UZI 
implements Unix well enough to run the Bourne 
shell in its full functionality. The only changes 
made to the shell's source code were to satisfy the 
limitations of the C compiler. 

Here is a (possibly incomplete) list of missing 
features and limitations; The debugger- and 
profiler-related system calls do not exist.The old 
6th edition seek() was implemented, instead of 



lseek(). The supplied TTY driver is bare-bones. It 
supports only one port, and most lOCTLs are not 
supported. Inode numbers are only 16-bit, so 
filesystems are 32 Meg or less. File dates are not in 
the standard format. Instead they look like those 
used by MS-DOS. The 4.2BSD execveQ was 
implemented. Additional flavors of exec() are 
supported by the library. The format of the device 
driver switch table is unlike that of the 7th Edition. 
The necessary semaphores and locking 
mechanisms to implement reentrant disk I/O are 
not there. This would make it harder to implement 
intemipt-driven disk I/O without busy-waiting. 

Miscellaneous Notes: 

UZI was compiled with the Code Works Q/C C 
compiler and the Microsoft M80 assembler under 
the CP/M operating system, on the same hardware 
it runs on. Also used was a version of cpp ported 
to CP/M, since the Q/C compiler does not handle 
macros with arguments. However, there are only a 
couple of these in the code, and they could easily 
be removed. 

Because UZI occupies the upper 32K of memory, 
the standard L80 linker could not be used to link it. 
Instead, a homebrew L80 replacement linker was 
used. This generated a 64K-byte CP/M .COM file, 
which has the lower 32K pruned by the CP/M PIP 
utility. This is the reason for appearance of the 
string "MOMBASSA" in fiUer.mac and 
loadunix.sub. 

To boot UZI, a short CP/M program was run that 
reads in the UZI image, copies it to the upper 32K 
of memory, and jumps to its start address. Other 
CP/M programs were written to build, inspect, and 
check UZI filesystems under CP/M. These made it 
possible to have a root file system made before 
starting up UZI, If the demand exists, these 
programs can be included in another release. 

Running programs under UZI: 

A number of 7th Edition, System V, and 4.2BSD 
programs were ported to UZI. Most notably, the 
Bourne shell and ed run fine under UZI. In 
addition the 4.2BSD stdio library was also ported. 
This, along with the Code Works Q/C library and 
miscellaneous System V library functions, was 
used when porting programs. 

Due to obvious legal reasons, the source or 
executables for most of these programs cannot be 
released. However, some kernel-dependent 
programs such as ps and fsck were written from 
scratch and can be included in future releases. 
Also, a package was created that can be linked to 
CP/M COM files that will allow them to run under 
UZI. This was used to get the M80 assembler and 
L80 linker to run under UZI. Cpp was also ported 
to UZI. However, it was not possible to fit the Q/C 
compiler into 32K, so all programs (and UZI itself) 
were cross-compiled under CP/M. 

The Minix operating system, written for PCs by 
Andrew Tanenbaum et al, contains many programs 
that should compile and run under UZI. Since 
Minix is much less encumbered by licensing 
provisions than real Unix, it would make sense to 
port Minix programs to UZI. In fact, UZI itself 
could be ported to the PC, and used as a 
replacement for the Minix kernel. 
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Affordable Microprocessor Development Tools 

by Tim McDonough 



Embedded Systems 

Beginners and Up 

Programming Tools 



Recently, I've received several letters 
from readers asking questions about past 
articles and questions in general about 
working with embedded systems. I re- 
ally enjoy hearing from you because it 
lets me know someone out there is inter- 
ested and it helps me figure out what 
direction to take for future articles. At 
the end of this article, I've listed several 
ways that you can contact me. My pref- 
erence, if you have the capability, is via 
one of the two forms of electronic mail. 
In most cases I answer e-mail the day I 
receive it. Besides, it saves trees and 
helps keep paper from piling up around 
here. 

The most frequently asked question I get 
is "Where can I get affordable develop- 
ment software for the (fill in the blank) 
microprocessor?" Affordable can mean 
different things to different people. In 
the case of the hobbyist or small business 
it typically means the cheapest thing that 
will get the job done. 

There are a lot of companies that pro- 
duce assemblers, compilers, and inter- 
preters for various microprocessors and 
microcontrollers. I'm not going to at- 
tempt to hst them all because I'm sure 
I'd miss someone with a great product. 
The tools I use are all MSDOS programs 
since the PC clone is my development 
platform. To my knowledge the products 
mentioned below are only available for 
that platform, 

A good source of reliable, solid cross- 
assemblers, simulators, and 
disassemblers is PseudoCorp. The Level 
1 demonstration versions of many of their 
cross-assemblers are available on many 
BBS systems and from major shareware 
vendors. I've personally used the 
commercial (Level 2) 8051, 68HC11, 



and 8096 products. Cost is about $50 
each for the Professional Level 2 
Assemblers. 

The PseudoCorp products were among 
the first that I used. Those of you that 
have followed my 803 1 articles here may 
recall that the program listings mention 
them. They offer feahires such as in- 
clude files, a powerfiil flexible macro 
facility and the ability to generate seg- 
mented object files for systems where 
your code and/or data spans several 
ROMs. In writing code for the TCJ ar- 
ticles I avoided using these features to 
make it as easy as possible for you to use 
the software of your choosing. 

Over the last few years there has been 
more and more interest in using high 
level languages, especially C, for em- 
bedded systems development. For the 
hobbyist or the small developer that 
meant drooling over compilers that cost 
anywhere from $800 to well over $2,000 
in some cases. I don't know what your 
hobby budget is like but for most people 
a $2,000 compiler is probably out of the 
question. 

A couple of years ago I ran across Dave 
Dunfield of Dunfield Development Sys- 
tems on a BBS. Dave has a remarkable 
collection of microprocessor software 
development tools that seems to grow 
each month. His flagship products are 
MICRO-C, a very portable C compiler, 
and his XASM series of cross-assem- 
blers. Currentiy his products are avail- 
able for the 6800, 680 1/6803, 6805, 6502, 
6809, 68HC11, 8051/8052, 8080/8085/ 
Z80, 8086 and 8096 microprocessors. 
Versions for the 68HC 16 should be avail- 



able by the time you read this. 

So, just what does affordable mean? 
Dunfield Development Systems sells a 
package that includes ALL of the assem- 
blers mentioned above with documenta- 
tion on disk for $49.95 plus shipping. If 
you plan to delve into multiple proces- 
sors and are going to stick with assembly 
language you probably won't find a bet- 
ter deal than Dave's XASM product. 

Sooner or later your projects will grow 
in complexity and unless there's an 
overriding need for flat out speed you'll 
probably yearn for a high level language 
to use for your projects. If you like C 
then Dunfield's MICRO-C for the 
processor of your choice is probably the 
best bargain you're likely to find in the 
embedded systems market. The 
"Developer's Kit" for a particular 
processor has just about everything you 
need to write code except the 
microprocessor manufacturer's data 
book. My MICRO-C 8051 package 
included the following items: MICRO-C 
805 1 compiler, ASM5 1 cross-assembler, 
optimizer, hand coded (in assembly) 
standard library fimctions (with source 
code), monitor/debugger (with source 
code), macro pre-processor, linker and a 
text editor. The best news—a 
"Developer's Kit" for any of the 
supported processors is only $99.95 plus 
shipping when you buy it direct from 
Dunfield Development Systems. 

MICRO-C is a K&R style C compiler. It 
provides features of special interest to 
the embedded systems developer such as 
being able to write interrupt handlers in 
C and extending the standard library 
with some additional bit manipulation 
functions. Other features include inline 
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assembly language capabilities and multi- 
line macros. 

There are a few drawbacks to MCRO- 
C that the C purist might criticize. Cur- 
rently there is no support for structures, 
unions, or bit-fields. There are also no 
floating point math fimctions or opera- 
tions. For the most part, the effect of 
these omissions on an 8-bit embedded 
system is negligible. In most instances 
coding techniques can easily work 
around these limitations. Of course if 
these things really bother you there's 
always those $2,000 systems. 

A word of caution-purchasing MICRO- 
C or any other high level language will 
not relieve you from learning the intrica- 
cies of the hardware for your target sys- 
tem. Unlike your PC or CP/M machine, 
there is no operating system or system 
services; more correctly, there are only 
those services you provide in the code 
you develop. There are no free rides when 
you're working with computers at this 
level. 

Writing articles doesn't mean I'm the 
last word on the subject of microcontroller 



hardware and software development. 
There are lots of talented folks out there 
and I'm sure a lot of them are more 
experienced than I am. Do you have a 
favorite piece of software you use that 
you think could help others? Drop me a 
note and tell me about it. I'd especially 
like to hear from you if you're using 
something other than an MSDOS com- 
puter. Let me know what's available for 
the developer that uses an Amiga, Atari, 
Color Computer, or CP/M machine. 
When writing please remember to tell 
me what machine it runs on, who pub- 
lishes it, and where to get it (BBS, direct 
sales, etc.) In fairness to all, please indi- 
cate if you are somehow associated with 
the publisher/manufacturer. I'll still 
mention your product if it's related to 
embedded systems work but I want to 
keep things on the up and up. 

Author Information 

Tim McDonough makes a living inte- 
grating remote measurement and con- 
trol systems with data communications 
systems and developing hardware and 
software systems for process control and 
data acquisition. He prefers to be con- 



tacted electronically if possible. 

Internet E-Mail: 

tmcdo450@athenanet. com 
BIX: tmcdonough 

US Mail: Tim McDonough 

Suite 3-672 

1405 Stevenson Drive 

Springfield, IL 62703 

USA 

Vendors Mentioned in this article: 

PseudoCorp (PseudoSam Assemblers/ 
Simulators) 716 Thimble Shoals Blvd. 
Suite E Newport News, VA 23606 (804) 
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Dunfield Development Systems (MI- 
CRO-C/XASM) P.O. Box 31044 
Nepean, Ontario (Canada) K2B 8S8 
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CLASSIFIED, FOR SALE and SUPPORT WANTED 



For Sale: GIMIX 6809 SS-50 floppy 
DMA disk controllers. Have six to 
sell at $25 each (plus shipping). These 
are like new and DOCS may be had 
for a fee. These were top of the line 
controllers for the SS-50bus system. 
Contact Bill at TCJ (916) 645-1670. 

For Sale: GIMIX FULL SYSTEM, 
6809 SS-50 box (very big and heavy), 
15 slot mother board, with several 
SS-30 slots. 6809 CPU, 64K memory, 
2 DMA disk controllers (8 and 5 1/4" 
drives supported), 2 serial ports, 1 
720K 5 1/4" drive and 1 360K 5 1/4" 
drive in case. Books, Disks, works, 
some programs (Forth, 

wordprocessor, etc.),currently running 
FLEX. $100 (plus shipping if not in 
San Francisco bay area). Contact 
Neale at (415) 892-1432, or Bill at 
TCJ (916) 645-1670. 



Support needed: Looking for help with 
South West Technical 6800 system. This 
is a tape cartridge unit (AC30). Trying 
to find tapes, docs, any help? Contact 
Todd Silk, at (208) 772,4631. 

Wanted: SAGE/Stride CP/M68k or 
UNIX software. Have a SAGE IV, (ac- 
tually II but labeled wrong) with 500K 
of memory. Also looking for hardrive 
for same. Want source code for CP/M 
BIOS and BOOT disk, have entire P- 
System with source code for that BIOS 
and ROMS. Complete set of DOCS and 
will copy what you need in exchange for 
software or support. Unix may not run 
on my system, but feel that I neeed to 
collect this information before it disapears 
for good. Interested in hearing about 
projects/uses you may be doing with these 
systems. Contact Bill at TCJ (916) 645- 
1670. 



The Computer Journal Classified sec- 
tion is for items FOR SALE, it is priced 
and setup the same as NUTS & VOLTS. 
If you currently have an ad running in 
NUTS & VOLTS, just send us a copy of 
the ad and your invoice from them, 
along with your check, and we will 
publish it in the TCJ. 

Classified ads are on a pre-paid basis 
only. The rate is $.30 per word for 
subscribers, and $.60 per word for oth- 
ers. There is a minimmn $4.50 charge 
per insertion. 

Support wanted is a free service to our 
readers who need to find old or miss- 
ing documentation or software. No 
FOR SALE items allowed, however 
exchanges or like kind swapping is 
permitted. Please limit your request to 
one type of system. Call TCJ at (916) 
645-1670. 
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Dr. S-100 



Regular Feature 



By Herb R. Johnson 



Intermediate 



Acquiring S-100 Skills 



Resurrecting your S-100 system 

My experience suggests that setting up a 
new S-100 system from old cards is like 
helping a person recover from a stroke: 
there is a period of tests to find damage, 
and stages of exercise to restore full func- 
tionality. New parts may be necessary, 
which also require an adjustment pe- 
riod. And, like a stroke, these events are 
rarely planned for. 

I was rewriting a Tarbell floppy disk 
controller BIOS for a SD Systems floppy 
controller recently. My development sys- 
tem was a Vector Graphics S-100 chas- 
sis, an IMSAI front panel, a Cromemco 
Z80 ZPU, and four CCS 16K static RAM 
cards. The memory cards feature an LED 
which hghts when the board is addressed, 
and DIP switch logic for independently 
addressing each 4K of memory. Static 
memory, by the way, is strongly recom- 
mended on the S-100 bus! Of course, 
the IMSAI front panel allows easy 
rdxx)ting and memory examination. The 
Cromemco ZPU is switchable between 2 
and 4 MHZ, ideal for debugging as you'll 
see later. 

As is my custom, I ran the assembler and 
trotted to the " httle programmers room. ' ' 
By the time I got back, all should have 
been assembled and the front panel blink- 
ing merrily away waiting for a keystroke. 
Instead, it was dark. After the appropri- 
ate calling down of the gods for daring 
to fail my "last" programming change 
of the day, my next reaction was.. what? 
What do you do when your system fails? 

Use your senses 

Before you grab a scope or even a meter, 
inhale through your nose repeatedly, 

i.e. smell! Is something burning? With 



experience, you can easily tell the differ- 
ence between the "toasty" smell of re- 
sistors, the "repaving the streets" smell 
of a fried transformer, and so on. With- 
out those experiences, you can still trace 
the odor to some source. My luck, I 
noticed no such smells. 

Next, use your hearing. Are the fans 
running? This will tell you if AC power 
is active (presuming you have AC fans. 
Some people, incidentally, have S-100 
systems without fans. They call them 
"heaters.") Of course, use your eyes! 
Do you see smoke? Are some boards lit 
up (hopefully with LEDs, not with the 
incandescent glow of components). If 
you find any catastrophic damage, shut 
down your system at once! 

Use your instruments 

Total failure (no lights) is actually good 
news! That limits the problem to the 
power supply or the AC source. In my 
case, however, no such luck. The front 
panel lights were on, but not blinking. 
The next step wasthe trusty voltmeter. 
Mine is a Radio Shack digital voltmeter, 
cost about $25, but any meter will do. 
Measure the power supply voltages. 
Generally it is easiest to do from the 
enormous capacitors that old S-100 sys- 
tems have; newer systems will have a 
nice set of power terminals to inspect. 
Measuring from the S-100 coimector is 
risky!! Positive and negative voltages 
are adjacent: a brief short will at least 
ZAP your fuses, and possibly your logic! 

Use your head 

My system showed no +8 voltage: thus 
the S-100 cards had no source for their 
+5 volt regulators. However, the AC side 
of the power supply had 1 lOV AC avail- 



able. To test my system power supply, I 
removed most of the S-100 cards, both 
to minimize possible damage from any 
accident and to see if reduced power 
requirements (or disengaging a board's 
shorted regulator) would change the re- 
sults. 

In diagnosis there is a pattern of behav- 
ior to follow: isolate, test, modify, re- 
peat Isolate a subsystem, test its opera- 
tion, modify a single feature of that sub- 
system, and test again. Repeat this cycle 
of modification and testing until you have 
either found a fault or verified the 
subsystem's operation. When you find a 
fault, isolate the fault area further and 
continue testing. 

Forward and retreat 

On my system, a resistance check of the 
rectifier diodes was good (forward resis- 
tance a few tens of ohms, reverse resis- 
tance very high). While a resistance check 
of the transformer did not suggest the 
windings were open, no voltage was 
produced at the secondary. What now? 

In principle, I could have torn down the 
chassis and thoroughly tested all fea- 
tures of the power supply. In fact, I pulled 
out the rest of the S-100 cards, and went 
to the garage to get another S-100 chas- 
sis. Meanwhile, I commend Mr. Payson 
for his foresight in keeping several S- 
100 systems as a repair resource. If you, 
however, enjoy building power supplies 
or have a source of Vector Graphic trans- 
formers, you could have fixed my sys- 
tem. It's all a matter of priorities, Re- 
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member, mine was writing a new BIOS. 

How to stabilize a "new" system 

My new box was from a banking system, 
and had a ftill load of cards itself. There 
is an art to pulling out a dozen S-100 
cards without shredding your hands on 
the IC pins which protrude like Punji 
sticks through each one. Hint: reach 
below each card to the bottom-most edge 
and push up. Practice helps. 

From my previous use, I knew the power 
supply on this box was operational. It 
was certainly powerful enough, noting 
the number of chips on each card I just 
pulled out. To make space for my front 
panel card, however, I would need a bus 
extender card. (Why? The IMSAI front 
panel card is 19 inches long, and rests in 
a special slot on the bus that is extended 
outside the S-100 card cage, which is 
about 10 inches wide.) As my previous 
Vector Graphic box also required an 
extender, this was no problem. So, I 
plugged in the front panel, the processor 
card, one memory card and powered up 
the new system. The Ughts on all the 
boards came on! This suggested that no 
board was seriously damaged, at least. 

"The helm is not responding, Captain. . . " 

My first tests were, of course, to read 
memory locations via the front panel. I 
quickly found that, although I could read 
an address, I could not use the NEXT 
ADDRESS or DEPOSIT NEXT switches 
to proceed to the next memory address! 
Was this a failure of the processor card, 
or the front panel card? I know the an- 
swer, and decided to deal with it another 
day. (Remember the BIOS I was Avrit- 
ing?) Who else out there knows the prob- 
lem? I'll tell all next issue. 

The fact that addressed locations had a 
variety of data values in them, as dis- 
played from the front panel, suggested 
"nominal" operation of all cards. I then 
added the Tarbell controller, the serial 1/ 
O card and all memory cards, and at- 
tempted to boot. I guess I didn't mention 
that I was using two 8" floppy drives - 
the ' 'small" hatf-height Mitibushi drives 
favored by Heath in their Z-100 systems. 
These drives, as do all 8" drives, have a 



distinctive sound to their operation that 
is critical to diagnosing boot-up faults. 

The sound of a "homing" drive is like 
drilling through wood, for instance. 

Allow me to elaborate further, to dem- 
onstrate the value of "deep understand- 
ing" as well as the power of the senses 
to determine computer operations. The 
floppy boot process involves homing the 
drive (a seek to track 0), followed ly a 
click or two as each track is sought (past 
tense of seek, sorry) and read. The con- 
tents of these ' 'boot tracks' ' is the CP/M 
operating system including the BIOS 
specific to your machine. However, you 
may hear instead the "homing" sound 
followed by a sound like trying to drill 
through a metal plate and failing: that is 
due to the confroUer not sensing the 
track line from the drive to stop the 
' 'home' ' operation, probably because the 
drive ready line is apparently not ac- 
tive. In my case, this occurred because 
the floppy drive I used did not have 
"terminating resistors" on its control 
lines that give the interface driver chips 
a source of current sufficient to "pull 
down" the disk drive's drive select or 
drive ready lines. (See figure 1 for the 
schematic of this scenario.) Of course, 1 
didn't know all this at once, so don't feel 
overwhelmed by this detail: experience 
comes with time and study. 

More ailments 

Once I added the terminating resistor 
pack, which was not needed by the 
Tarbell controller but necessary to the 
SD Systems confroller, I heard the fa- 
mihar "clunk-a-thunk' ' operation of the 
A drive. However, I did not get the final 
" A>" prompt on the screen. Again from 
experience, this is a typical symptom of 
some kind of memory fault. An area of 
memory vital to CP/M was absent, or a 
memory chip was bad, or the processor 
was running too fast for some area of 
memory to respond reliably. 

Another possibility was poor contact on 
the S-100 bus by one or more cards. 
Unfortunately, this is a chronic problem 
in any system with hundreds of edge- 
contact points (i.e. number of cards 
multiplied by the number of bus cormec- 
tions per card). Age and storage make 



the problem more acute - kind of a "hard- 
ening of the arteries." The cure is a 
combination of edge connector cleaning 
and careful "seating" and reseating of 
the cards into the connectors. Observe 
any residue on the coimectors. Try to use 
contact cleaner and a soft cloth to clean 
the edge of the board. Alcohol-based 
cleaners will degrade the plastics; and 
pencil erasers can be abrasive. A soft 
artist's eraser is better. Even pieces of 
paper, or a toothbrush with a small 
amount of soapy water followed by clear 
water, can make a difference. By the 
way, poor contacts are also a problem 
with IC sockets: examine these closely 
as well! 

As for memory tests, try to run some 
large programs that will use all available 
memory; or switch suspect areas of RAM 
into or out of active memory space. A 
general memory test program is better 
still. You can at least use CP/M's DDT 
to fill and examine memory areas. Again, 
if your processor card has switchable 
speeds, run your system "too fast" to 
highlight errors. Note: hot IC's, includ- 
ing memory chips, fail at lower speeds 
than cold chips. For subtie errors, I've 
resorted to putting S-100 cards in the 
freezer and using a hair dryer to exag- 
gerate temperatiu-e-based errors. 

Running at last! 

By a combination of the above, working 
on it over a few evenings, I finally re- 
established a running and stable system. 
All this may seem to be a lot of work to 
some of you. But, consider what we have 
learned about disk controllers, memory, 
contacts, and so on. The modular nature 
of the S-100 bus is ideal for repair and 
for self-education. My "lost" time is a 
gain for you if you have picked up some 
hints on testing and repairing your sys- 
tem! Have fiin, and tell me what you 
have learned when it's your turn to res- 
urrect your computer. 

Letters and notes 

Larry Cameron writes from GEnie (via 
his IMSAI!) on how he feels he may be 
"the only person crazy enough to be 
doing something like restoring old 'ob- 
solete' computers" and hopes that TCJ 
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will "continue S-100 stuff." Larry, I 
hope my previous column shows a good 
beginning. I hear from a number of 
people who enjoy ' 'antique computing, ' ' 
but rarely are any two of them in the 
same city! For communications, you have 
to go to national or international sources. 
I recommend the CP/M Tech echo on 
the BBS FidoNet network; I've also heard 
good reports about a similar echo on the 
Internet. Look at the end of my column 
for contacts. 

Eliot Payson of Littleton CO says he 
"has several S-100 machines in various 
stages of disrepair. " Well, join the club! 
Your condition is normal for the true S- 
100 fan! I think you'll like my column 
this month! Ehot also sent me, inciden- 
tally, a copy of his club's newsletter, and 
I hope our Editor Bill Kibler will ' 'plug' ' 
it in more detail. 

Some time ago, Gary Stagliano of 
Manchester CT wrote to me and asked 
about MYZ80. I'll refer him to die Sept/ 
Oct 92 issue of TCJ for the brief from 
Lee Bradley. Incidentally, thanks to 
Lee's BBS, I have the latest version of 
Simeon Cran's MYZ80. As an early 
beta tester, I too am encouraged by this 
product. However, as currently distrib- 
uted it lacks development 
documentationessential for any "tinker- 
ing" programming. I'll encourage such 
docs by contributing some of my ' 'inves- 
tigations" to Lee's board. See his col- 
umn for contact info. 

Resources 



HOST SYSTEM 



MAX 10 FEET 
FLAT RIBBON OR 
TWISTEDPAIR 




•These lines are alternate 
Not shown are pins 4. 6, 



input/output lines and they are enabled bv plugs. Reference section 7 for uses of these lines, 
and 8 which are laternale I/O pins. 



FidoNet: an international network of 
Bulletin Board Systems, usually with 
small or no subscription charges. It sup- 
ports a number of informational exchange 
areas, including one for CP/M called 
' 'CP/M Tech. ' ' Contact your local com- 
puter club for a list of local boards which 
may carry FidoNet. 

Internet: another international computer 
network, but harder to get onto for free 
as it is usually associated with universi- 
ties or other institutions. Contact your 
local university's computer center for 
details. 

Lee Bradley's Z-Node #12: (203) 665- 
1100 in CT. 



=04- 



7407/7438 



SA850 



MAX 10 FEET 
RIBBON OR 
TWISTED 
PAIR 
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Figure 1 : Disk Drive and Controller Interface 
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Regular Feature 

Kaypro Support 

Moving the Reset Button 



Mr. Kaypro 

By Charles B. Stafford 



This is the first of a series of articles, the 
thrust of which is to make your hard- 
ware more friendly to the only user that 
counts, YOU. All of the modifications 
described will be possible with only or- 
dinary hand tools, all of these modifica- 
tions have been done by the author who 
has two left thumbs and is supposed 
(according to his mother) to be right- 
handed. Although the platform involved 
is a Kaypro, the principles are applicable 
to any machine, and the use of the Kaypro 
as an example, is only because that's 
what I happen to own. I am available for 
questions most evenings at (916) 482- 
8305. 

The RESET Button 

The Reset button on the Kaypro is 
mounted on the rear panel some- where 
in the vicinity of the top right corner. 1 
say "somewhere" because the exact lo- 
cation varies with the age and type. 
Perhaps I am more adventurous than 
most, but I seem to get my trusty side- 
kick "hung" rather frequently, and it 
occurred to me once as I wished for a ten 
foot right arm, that I could correct 
Kaypro's design error. I'm sure that the 
designers put the Reset button where 
they did out of concern that it not be 
accidentally activated and to make sure 
that its use was the result of a conscious 
decision, but it certainly was inconve- 
nient. The bottom line was that it be- 
longed it on the front panel. 

A little research (removing the cover) 
revealed that the proposed location was 
clear of any interference, and that the 
wires were long enough to reach. It also 
became apparent that the actual button 
was mounted from the rear of the panel, 
and held by a serrated ring screwed on 
from outside, and only finger tight, 



Here is how we do it. 

As it says in all the manuals, unplug the 
power cord not only from the wall, but 
also from the computer (unless you have 
a really early one where the line cord is 
mounted in a strain relief). Remove the 
cover careiully, and put the screws (10 
for a Kaypro) in a safe place. I use those 
plastic cans that film comes in to keep 
track of the screws. 

Decide where the new location is, make 
sure it will be clear of any folding key- 
boards, and leave some room for another 
front panel modification later. Mine is 
centered between the monitor and the 
drives, about an inch and a half above 
dead center vertically. Put a piece of 
masking tape over the spot, do your final 
measurements and mark the spot on the 
tape. If you have a center punch and are 
a purist, this is the time to use it. 

Next comes the sneaky part. We use a 
six inch piece of two and a half inch duct 
tape, you know, McGyver 's favorite tool, 
and make a tent over the back side of the 
new location (on the inside surface of 
the front panel). Pinch the sides of the 
tent shut and we have a ' 'pouch' ' over 
the place we're going to drill to catch all 
the shavings and filings. 

Here comes the scary part ! 

Using your favorite electric ( OK, Hand) 
drill a 3/16" pilot hole being carefiil not 
to hit the duct tape, and then a 3/8" hole. 

Remove the masking tape, smash the 
duct tape pouch down on the inside of 
the front panel to trap all the nasty things 
and remove it carefully along with the 



trash. Clean up the hole if necessary and 
the hard part is done. 

One last bit of surgery, the wires going 
to the Reset button are fastened to the 
right stand-off (support) for the 
motherboard by a small plastic ty-wrap 
which must be cut. Diagonal cutters 
work just fine. 

The fun part 

Unscrew the plasfic ring that secures the 
Reset button, move the button assembly 
to the new hole and reinstall the retain- 
ing ring. 

Carefully check the area under the new 
location to make sure no metal chips got 
away, replace the cover and screws and 

YOU'RE FINISHED. 

When you realize the convenience of the 
new location, you may start thinking 
about the video brightness control. The 
only differences are 1. the knob ; 2. the 
wires will have to be extended. Other- 
wise the operations are the same. 

Good Luck, and May You Live Long. 



Chuck has proposed some articles for 
his next column unless our readers flood 
him with requests for information and 
help. The proposed articles include: A 
replacement of the 65 watt power supply 
with a pc-xt 150 watt power supply. A 5 
Mhz speedup. A side select modification 
to convert early ssdd machines to dsdd. 
A Construction of a 4-drive decoder 
(TurboRom). If you have any special 
ideas or problems, give Chuck a call, 
and he will help you in resloving those 
Kaypro problems. BDK 
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Computing Timer Values 

By Clem Pepper 
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Intermediate Support 
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' It 's test time ' ', at least that 's what I say to my students For 
those who like to see if you remember your fundamental 
electronic skills, here is an article about timers and calculat- 
ing the resistors and capacitors. This article also shows an 
appropriate use for doing something in "C. "Read on and see 
if you can pass the fundamentals test. BDK 

COMPUTE IC MONOSTABLE AND TIMER VALUES 
WITH THESE C PROGRAMS 

IC monostable equations appear to be straightforward for the 
most part. They should present but few difficulties. But there 
is a catch: keeping track of the decimal points. Resistors are 
in M ohms, K ohms, or just plain ohms. Capacitance in micro- 
, nano-, and picofarads. Pulse widths in whatever 
submicrofraction of a second. Not to mention time spent 
thumbing through data manuals in search of an equation. 

Well, here are two programs to do away with all that. The one, 
MONO.C, solves for any one of three variables when given the 
two known for thirteen popular IC monostables. The other, 
TIMR.C, solves for two of the five variables for the 555/556 
timer in the astable mode. (Solutions for the monostable mode 
are provided in MONO.C.) Both programs are fully menu 
driven. In addition to calculation of component values and/or 
timing testing is performed for over/under limit conditions 
where these occur. If a limit is exceeded an explicit error 
message is displayed. 

The programs are written in C. They should compile with any 
C compiler. I took care to avoid code that would limit the 
portability. For that reason MS DOS ANSI functions are used 
for cursor and screen clearing tasks. My original code was 
written in 1986 using The Software Toolworks TOOLWORKS 
C compiler. I recently recompiled it with Borland's Turbo C 
version 2.0 with only minor revisions. If you do not have a C 
compiler a disk containing both the source and executable code 
for a PC or compatible is available from the author. 

Using The Monostable Program 

For PC clone users, be sure that DEVICE=ANSI.SYS is in- 
cluded in your computer's CONFIG.SYS. 

Table 1 is a listing of the timing equations for the IC monstables. 
In its operation the program first displays the 13 IC types. It 



then queries for the type and the variable to solve fOr. The three 
monostable variables are the pulse width, the timing resistance, 
and the timing capacitance. You are asked to enter the two 
known. The solution for the third is then calculated and 
displayed. If a component value exceeds a limit for the device 
an error message is displayed. The program can be run 
repeatedly without exiting from it. 

The program begins with a display of the monostables for 
which a solution can be made. This is: 

Hi! Enter the letter matching the mono of your choice 
from the selection below. 

A = 9600 E = 74122 I = 74LS221 
B = 9601 F = 74123 J = 74C221/4538 
C = 9602 G = 74LS123 K = 4528 
D = 74121 H = 74221 L = 555/556 

The first step, then, is to enter the letter corresponding to the 
device of interest. 

In response the program prints a verification request using the 
device number. 

Is the 74LS123 the mono you want? <Y/N> : y 

Pressing "y" (or "Y") causes the program to continue. If 
"n" (or "N") is pressed you are asked to make another 
selection. 

Assuming the entry is for the desired mono you are asked to 
select from one of the following options: 

Type in T if the program is to solve for the pulse width: 
Type in C if the program is to solve for the timing capacitor: 
Type in R if the program is to solve for the timing resistor: 

Suppose we enter "t" (or "T") for the pulse width. We are 
then queried for the two remaining requirements - the timing 
components: 

Enter your timing capacitor requirement, CV : 1 
Enter multiplier M=mfd : N=nfd : P=pfd : n 
Enter your timing resistor requirement, RV : 47 
Enter multiplier O=ohms : K=kohms : L=mohms : k 
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In this example we are using a one rafd capacitor with a 47K 
resistor. With this information provided the program calcu- 
lates the pulse width and displays it's value along with the two 
given inputs. 

TV = 21.15 uSec is the pulse width solution. 
CV = 0.001 MFD is the timing capacitor solution. 
RV = 47000 OHMs is the timing resistance solution. 

We are then given the opportunity to continue with another or 
the same device with changed values or to exit the program. 

Do you wish to continue with new input <Y/N>? : n 

This sequence as it appears on our screen is illustrated in 
Figure 1. 

The Monostable Program 

The program source code is given in Listing I. (The line 
numbers are for convenience only, not a part of the code.) 
Comments are used throughout to aid in its understanding. 
Defines and global declarations head the listing, preceding the 
instruction code. Program operation begins with the function 
mainQ. There is nothing particularly devilish about the code 
with the possible exception of the use of structure variables. 
Their primary purpose is to simplify the logic for the printfO 
statements. 

Each fiinction call is preceded by comment describing its 
purpose. A comment stating the source of the call is also 
provided. Each call to scanfQ is followed by a call to flush the 
keyboard buffer. Without this call the program will leap over 
the next query. This arises from a bug in the scanfQ library 
fiinction. 

The heart of the program is in the fiinction mon_calc0 Here 
is where the program learns which variable it is to solve for. 
The variables ms, rnl, rn2, and rn3 (refer to Table 1) are then 
assigned. Variable mdl was assigned earlier in monoJnpO 
when you entered the device letter. 

Following the assignments the program queries for the two 
known quantities and their multipliers. The actual multiplier 
is assigned with a call to sca_parO A call is then made to 
equatnO for calculation of the unknown. The assignment 
variable ms is passed in the fiinction call. Note that assign- 
ments for three quantities - TV, CV, RV - are made in this 
fiinction. 

On return from equatnO the three values are displayed. An 
advantage of C's structure is seen in the simplicity of the 
printfO statements. 

A test then follows for limits. Should one or more be exceeded 



an error message is displayed. 

Using The Timer Program 

Table 2 is a listing of the 555/556 equations. In its operation 
the program first displays the five variables and instructions on 
their selection. You are asked to enter the two unknowns for 
which you want solutions. You are asked to verify these - a 
chance to change if desired. You must then provide informa- 
tion on the remaining three variables. Solutions are then 
calculated and displayed. No limits on component value exist. 
There is, however, an upper limit of 0.33 for the dufy cycle - 
an error message is displayed if this is exceeded. Also for 
negative values in any solution. The program can be run 
repeatedly without exiting from it. 

On typing TIMR and pressing RETURN the screen first clears 

and then displays the following: 

Hi! Pick two variables for solution from the table below. 

Enter them in ascending order (b e, not e b). 

Follow each with a RETURN: 

A = ONE CYCLE TIME, TT. TT = t(low)+t(high). 
B = THE DUTY CYCLE, DC. DC = t(low)ArT 
C = THE TIMING CAPACITANCE, TC. 
D = THE UPPER RESISTANCE, RA. 
E = THE LOWER RESISTANCE, RB. 

Note: Do not select A and C as a pair. 
An entry is not a commitment till you make it so. 
If you flub, just continue on, till queried. 
Then enter N to start over. 

Note that we cannot obtain a solution for the dufy cycle and the 
timing capacitance as a set. 

In this example the solution for the two resistors, RA and RB, 
is desired, so we fype "d" (or "D") followed by a RETURN, 
the "e" (or "E"). Again followed by a RETURN. Like so: 



d 

e 



We are given an opportunify to change our minds: 

Are D and E what you want? <Y/N> : y 

Assmning happiness with our selection we enter "y" (or 
" Y"). We are then queried for the three remaining variables: 

Enter your one-cycle time requirement TT: 5 
Enter multiplier S=seconds : T=mS ; U=uS : : t 
Enter your duty cycle (must be <.33) requirement DC: .2 
Enter multiplier - No multiplier for DC. Press RETURN.: 
Enter your timing capacitor requirement TC: .05 
Enter multiplier M=mfd : N=nfd : P=pfd : : m 

In this we have chosen 5 mS for the period, a dufy cycle of 0.2, 
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and a timing capacitance of .05 mfd. The resistance solutions 
follow: 



money order for six dollars ($6.00) along with your mailing 
address to 



RB = 2,89e+04 OHMS is the lower resistance solution. 
RA = 8.66e+04 OHMS is the upper resistance solution. 
TT = 5e+03 ; DC = 0.2 : TC = 0.05 



C. S. Pepper, 

13409 Midland Road, Apt. 175 

Poway, CA 92064 



As with the monostable program we have the option of con- 
tinuing: 



A photocopy of the referenced article is also available for 
$2.00. Allow three to four weeks for delivery of these. 



Do you wish to continue with new input <Y/N>? n 

Usually we know the frequency and duty cycle of the desired 
waveform. Capacitor values adhere closely to a fixed numeri- 
cal scheme. The most flexibility and our greatest need to know 
is with the resistors. The effect of going to the nearest standard 
resistances is easily checked by their substitution and solving 
for the period, capacitance, and duty cycle. 

The preceding sequence as it appears on our screen is illus- 
trated in Figure 2. 

The Timer Program 

The program source code is given in Listing 2. It is similar in 
its construction to MONO.C. Although shorter it is somewhat 
more complex in having to deal with five variables. As with 
MONO.C the program takes advantage of #defmes and the 
structure. The structure may look strange in that there are 
repetitions for the resistance variables RA and RB. This arises 
from the multiple solutions for these and the manner in which 
the data is displayed. Table 2 includes the program assign- 
ments associated with each of the possible solutions for all the 
variables. 

The heart of the program is in the function ast_calcO. As in 
mon_calcO the program learns which variables relate to the 
unknowns (refer to Table 2). This fiinction is more complex 
than its monostable counterpart in the number of possible 
combinations that exist. As in MONO.C scaling takes place 
in sca_parO. 

Two calls are made to equatnQ and the values displayed. A 
test for the duty cycle and any negative results follow. 

Reference 

Pepper, Clement S. 

"A Monostable Catalog For Experimenters" 

Popular Electronics, September, 1979, pp 69 - 79. 



A Program Disk 

A disk containing the equation tables, C source code, and the 
run files (.EXE) for the two programs is available from the 
author. Disk format may be any IBM compatible mode: 5 1/ 
4 360 Kyi.2M or 3 1/2. To obtain the disk send a check or 



»»***«»«»«****«»»»*»»»»«»«»»«»*«*« «/ 



2; /• »»4.«»««***«»«**»»» MONO.C »••««•*••••••*•' 

4: /* A program for calculation of IC monostable */ 

5' /* variables ************************** **■*■**** * 

6: /* by Clement S. Pepper -*•**•* **•• * 

8: 

9: #mclude <stdio.h> 

10: 

11: /* = function prototypes = ■/ 

12: void inainO,inono_inpO, error_inO, y_n_veiO. 

13: inon_calc0, eqiiatn(int), sca_par(char), repeatQ, 

14: 

15: /* DEVICE=ANSI.SYS required in CONFIG.SYS •/ 

16: ^define CLRSN "\033(2J" /' Clear the screen */ 

17:#defineCURUP"\033(A" /* Cursor up one row •/ 

18: «define CURBK "\033|D" /• Cursor left one col •/ 

19: #dc£ne CURLS "\033|K" /• Erase to line's end •/ 

20:#de£ne ERASE"" /• Erase one space •/ 

21: #define POSCUR "\033[9;1H" 

22: /* position cursor line 9, col 1 */ 

23: /* = global variables ^= */ 

24: int rerr; /* Resistance limit enor flag */ 

25: int mdi; /* Monostable device identifier */ 

26: float sin; /• A monostable solution transfer var */ 

27: float sen; /* A monostable scaling transfer var */ 

28: float sel;/* Transfer variable for 1st var •/ 

29: float se2; /* Transfer variable for 2nd var •/ 

30: float TV; /• Timing variable (pulse width) */ 

31: float CV; /• Capacitance variable "/ 

32: float RV; /* Resistance variable */ 

33: 

34: /* ^^= mono identification stmctuie = */ 

35: /• = Relates menu to device type = */ 

36: struct monose! { 

37: char *ic_5el, /• User selection code */ 

38: char "icdev; /* Monostable ID number */ 

39: )selattr(121=( 

40: /* ic sel ic dev */ 



41:/- 

42: "A" 



43: 



"B", 
"C", 
"D", 
"E", 
"F", 
"G", 
"H", 
"1", 
"J", 
"K", 
"L", 



•/ 

"9600", 
"9601", 
"9602", 
"74121", 
"74122", 
"74123", 
"74LS123", 
"74221", 
"74LS221", 
"74C221/4538" 
"4528", 
"555/556" 



*/ 



45: 

46: 

47: 

48: 

49: 

50: 

51: 

52: 

53: 

54: ); 

55: 

56: /' = mono solution message structure = 

57: stmct monocal { 

58: chai 'parmtr; /* Parameter variable assigned */ 

59: chai *p_stig, /■ Mono parameter sbing msg */ 

60: char *solmsg; /* The solution message 

61: chai *multi; /• Data scaling fectors 

62: ) calaHr[31 = { 

63: /• parmtr pstr^ solmsg */ 

64:/' •/ 

65:/* multi •/ 

66:/' — - •/ 

67: "TV","pulse width", "uSec is the pulse width solution ", 

68: "S»Sec:T'TnS:U=uS", 

69: "CV", "timing capacitor", 

"MFD is the timing capacitor solution-", 
70: " M=mfd : N=nfd : P=pfd" , 
71: "RV","timing resistor", 

"OHMs is the timing resistance solution.", 
"OKthms : K=kohms : L^mohms" 



•/ 



•/ 



), 

/* = resistance error structure " 
stmct r_erTor { 
char *r_limit; 

}erattr[91 = ( 
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89: 

90; 

91 

92: 

93: 

94: 

95: 

96: 

97: 

98: 

99: 

100: 

101 

102 

103: 

104: 

105: 

106: 

107: 

108: 

109: 

110: 

HI 

112: 

113: 

114: 

115: 

116: 

117: 

118: 

119: 

120 

121: 

122: 

123: 

124: 

125: 

126: 

127: 

128: 

129: 

130: 

131 

132: 

133: 
134: 
135: 
136: 
137: 
138: 
139: 
140: 
141 
142 
143: 
144: 
145: 
146: 
147: 
148: 
149: 
150: 

151: 

152: 
153: 
154: 
155: 
156: 
157: 
158: 
159: 
160: 
161: 
162: 
163 
164: 
165: 
166: 
167: 
168: 
169: 
170 
171: 



"<1400","<2000","<5000","<10000",">40000", 
">50000",">100000",">350000",">1000000" 

); 

/* = Begin Program = */ 
void TtiainO 
{ 
printfl:"%s",CLRSN); /"" Clear the screen */ 

/* ** Mono selection menu •* •/ 
printfl;" Hi! Enter the letter matching the 

mono of your choice\n"); 
printf(" from the selection beiowAn^"); 

A = 9600 E = 74122 I = 74LS221 \n"); 

B = 9601 F = 74123 J = 74C221/4538\n"), 

C = 9602 G-74LS123 K. = 4528 W); 

D = 74121 H=7422l L = 555/556 \n\n"); 



printf('" 
printfl;*' 
prints;*' 
printfl;" 
mono_inpO; 
) 



/" = Assign value to mono type identifier, mdi = •/ 
void monoinpO /• From: mainQ, error inO, y_n_verO */ 

( 

char sel; 

sel = getchO; 
switch(toupper(sel)) { 

case 'A': mdi = 0, y_n_verO, mon_calcO; /* 9600 
case 'B': mdi== 1; y_n_verO, mon_calcO, /* 9601 
case 'C: mdi = 2; y_n_verO; mon calcO; /* 9602 
case 'D': mdi = 3; y_nverO; moncalcO; /* 74121 
case 'E': mdi = 4, y^n^verQ; mon_calcO; /* 74122 
case 'F': mdi = 5, y_n verQ, moncalcQ; /* 74123 
case 'G': mdi = 6; y_n_verO;mon_calcO;/* 74LS123 "/ 
case 'H': mdi = 7; y_n_verO, mon calcO;/* 74221 *'' 
case 'r:mdi = 8; y_n_verO, mon_calcO./* 74LS221 */ 
case 'J': mdi = 9; 'y_n vert); mon calcQ; /* 74C22 1/4538 */ 
case 'K': mdi= 10;y_nver(); mon_calc(), /* 4528 */ 
case 'L': mdi = 1 ! ; y_n_verO, moncalcQ; /* 555/556 ■/ 
default: piintfl:''%s%s%s%5",CURUP,CURBK,ERASE,CURBK), 
errorinO; 



*/ 
*/ 
*/ 
*/ 
•/ 
•/ 



) 



/• = Display error message in menu selection = " 
void error_inO /* From: mono_inpO */ 
{ 
printfl;' ' Your entry is outside the menuAn' "): 
printfC ' Please re-enter your selectionAn' "); 
monoinpO; 



/* = Requestor selection confirmation = */ 
void y_n_verO ^* From: monoinpO */ 

{ 

char verify, 

printf("\tls the %s the mono you want? <Y/N> ", 

selattr[mdil,ic_dev), 
verify = getchO, 

if(toupper(verify) ^ 'Y') { printfl;'"\n"); reUim; ) 
else printfi:*'%s%s",POSCUR,CURLS); 

printf("\tPlease re-enter your selectionAn"); 
mono inpO; 



/* = Variable inputs and calculations, display of results, = 
void moncalcQ /* From; monoinpO */ 

{ 

char par, scale; 
/• par - parameter input for solution: T, C, or R */ 
/* scale - multiplier input by user '/ 

intml,m2, m3, ins, 

/"ml. m2, m3 - struct monocal routing code */ 
/* ms - monocal structure identifier */ 

piintfi;" *\tType in T if the program is to solve for the 

pulse width: *ji"), 
piintfi:*'\tType in C if the program ts to solve for the 
tinting capacitor: \n"); 
prints "\tType in R if the program is to solve for the 

timing resistor: \n"), 
/* *• Enter parameter for solution: 'R', 'C',or'T' "* */ 
par = getchO; 



■ Assign vaiiables for identifying parameters R, C, or T * 



/• •• solve for the resistance *• */ 
ifttouppertpar) ^ 'R') { 

ml =0;m2= l,m3 = 2, 
if^mdi = II mdi = 1 II mdi = 4) (ms=17, ) 
/• 9600, 9601,74122'/ 
else iflradi = 2) ( ms =■ 18, ) /- 9602 •/ 
else ifi:mdi = 3 || mdi = 7 i| mdi = 8) { ms = 19; ) 

/" 74121, 74221, 74LS221 •/ 
else ittmdi — 5) { ms - 20, ) /- 74123 '/ 
elseiftmdi = 6) { ms = 21. ) /' 74LS123 •/ 
else iftmdi = 9) { ms = 22, ) /* 74C221,4538 */ 
else iRmdi = 10) { ms - 23, ) /• 4528 •/ 



172 
173: 
174: 
175; 
176; 
177: 
178: 
179; 
180; 
181 
182 
183; 
184; 
185; 
186: 
187; 
188: 
189: 
190; 
191 
192 
193; 
194; 
195; 
196; 
197; 
198: 
199: 
200: 
201 
202: 
203: 
204: 
205: 
206: 
207: 
208: 
209: 
210: 
211 
212: 
213: 
214 
215 
216: 
217 
218: 
219 
220: 
221 
222: 
223: 
224: 
225; 
226: 
227: 
228: 
229: 
230: 
231 
232: 
233: 
234: 
235: 
236: 
237: 
238: 
239: 
240: 
241 
242: 
243: 
244; 
245: 
246: 
247: 
248: 
249: 
250: 
251 
252; 
253: 
254: 
255: 
256: 
257: 
258: 
259: 
260: 
261 
262: 
263: 
264; 
265; 
266' 
267: 



else ilCmdi = 1 1) ( ms - 24; ) /' 555/556 •/ 

) 
/* ** solve for the pulse width •* */ 
else ifttouppei(par) ^ 'T') { 

ml = l;m2 = 2,m3-0, 
iftmrti = 0||nidi=l |jmdi = 4) { ms= 1.) 

/• 9600,9601, 74122'/ 
else if^mdi — 2) { ms - 2; ) /' 9602 */ 
else iHmdi — 3 || mdi — 7 || mdi = 8) { ms - 3; ) 

/' 74121, 74221, 74LS221 "/ 
else ifCmdi = 5) { ms = 4; ) /* 74123 •/ 
else ifi;mdi = 6) ( ms - 5, ) /• 74LS123 */ 
else iflmdi = 9){ms=6;)/'74C221 ,4538 '/ 
else iffnidi = 10) ( ms = 7; ) /' 4528 '/ 
else ii(mdi = 1 1) { ms = 8; ) /' 555/556 */ 

) 
/' " solve for the capacitance " */ 
else ifl;toupper(par) = 'C') { 

ml=2,m2-0;m3=l; 
ifi:mdi = 0||mdi— 1 ||mdi-=4) { ms - 9;) 

/' 9600,9601,74122*/ 
else if^mdi = 2) ( ms » 10, ) /• 9602 •/ 
elseifi;mdi = 3||radi = 7||mdi = 8) { ms = ll,) 

/• 74121, 74221, 74LS221*/ 
elseifi:mdi = 5) { ras- 12, )/* 74123 */ 
else iffmdi = 6) { ms - 13, ) /' 74LS123 '/ 
else ili:mdi = 9) { ms = 14; ) /• 74C22 1,4538 '/ 
else iHmdi = 10) { ms = 15; ) /• 4528 •/ 
else ifCmdi = 1 1) ( ms = 16, ) /' 555/556 •/ 
) 

/* ' * Enter 1 st known pami and scaling required * * */ 

printf("\n"); 

printfC'UEnter your %s requirement, %s : ",calattr[ml].p_stTg,\ 

calattr[ml].parrntr); 
scanf("%f \&sel); fflush(stdm); 

printfl;"\tEnter multiplier %s : ",calattr[ml].mu]ti); 
scanff"%c'\&scale); fflush(stdin); 
sen = sel; sca_par(scale), sel = sen; 

/* ** Enter 2nd knowTi par and required scaling ** */ 
printft"\tEnter your %s requirement, %s : ",calattr[m2].p sti^,\ 

calattr[m2]-parmtr); 
scanfl:"%f ',&se2); £Qush(stdin); 

printf("\tEnter multiplier %s : ",calattr[m2].multi); 
scanfi;"%c",&scale); f!lush(stdin); 
sen = se2; sca_par(scale), se2 = sen, 

/* "* Get solution for unknown parameter ** */ 

equatn(ms), 

printtt"\n\t%s = %g %s\n",calattr[m3].parmtr,sln,ca]attr[m3].solmsg); 

printft"\t%s = %g %s\n",calattr[ml].parmtr,sel,calattr[mll.solm5g); 

printft"\t*/os = %g %s\ii",calattr[m2] parmtr,se2,calattr[m2].solmsg); 

/*•*■•***"■** ERROR MESSAGES •*•*«■*-**•/ 
/* ** RESISTANCE UNDER/OVER LIMIT VALUES " */ 
ifl:mdi = 3) {iftRV<:l400)rerr= I, } 
if(mdi = 7 li mdi = 8) { iftRV <2OO0) ren = 2, } 
ifi:mdi = 0||mdi=l || mdi = 2 |j mdi = 4 ||mdi=5 
jl mdi = 6 II mdi =10) 
{ifi;RV<5000)rerT = 3, } 
ifl:mdi = 0||mdi=l ||mdi=-2){if(RV>25000) reTT = 4; } 

ifl;mdi = 3) { iflRV >40000) rerr = 5, } 
ifl:mdi=4||radi=5||mdi = 6) { iffRV >50000) ren = 6; ) 
ifl:mdi = 8) { iftRV > 100000) rerT = 7; ) 
ifi:mdi = 9) { iftRV >350000) rerT = 8, } 
ifl:mdi=10){iftRV>t000OO0)rerT = 9, } 

/* *• Print resistance under/over error message ** */ 
iffrerr !- 0) { 

printf("\n\tA resistance %s is unacceptable for the %sAn",\ 

erattr[ren-l].r_limit,selattr(mdi],ic_dev); rerr = 0; 
pnntft"\tSelect a new value for R and begin again.\n"); 

) 
/- •• CAPACITANCE OVER LIMIT VALUES •• •/ 
ifi;mdi = 3||mdi = 7|imdi = 8) {ifi:cv>1000) { 
printft'*\n\tCapacitance>fOOOmfd is unsatisfectory for the %s .",\ 

selattr[mdi] icdev); 
printft''\n\tSelectnewanewvalue for C and begin again."); } 

) 

repeatO, 



/* ^= Solve for the unknown parameter = */ 
void equatn(ms) /* From: mon_calc() */ 
intms, 

( 

intlvcc; chardcv; 

/• Ivcc - natural log value for VCC */ 

/' dcv ■ code for 4528 DC voltage mput '/ 
iftms = 711ms = !5||ms = 23) ( 

printf^"\n\tEnter one of the following code numbers for the 4528 VCC"); 

pitnti("\n\t If your VCC is 5 volts enter 1 ' '); 
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268: 
269: 
270: 
271: 
272: 
273: 
274: 
273: 
276: 
277: 
278: 
279: 
280: 
281: 
282: 
283: 
284: 
285: 
286: 
287: 
288: 
289: 
290: 
291: 
292: 
293: 
294: 
295: 
296: 
297: 
298: 
299: 
300: 
301: 
302: 
303: 
304: 
305: 
306: 
307: 
308: 
309: 
310: 
311: 
312: 
313: 
314: 
315: 
316: 
317: 
318: 
319: 
320: 
321: 
322: 
323: 
324: 
■325: 
326: 
327: 
328: 
329: 
330: 
331: 
332: 
333: 
334: 
335: 



printff'Wt If your VCC is 10 volts enter 2"), 
printfC'Wt IfyourVCCis 12 volts enter 3"), 
printf("\n\t If your VCC is 15 volts enter 4"), 

/• •• input code for VCC *• */ 
dcv = getchO; 

/* •• Calculate natural log of VCC " •/ 

if(dcv = ' 1 ') Ivcc = 1 609; 
else iffdcv = '2') Ivcc = 2.303; 
else iffdcv = •3') Ivcc = 2 485, 
elseiffdcv— '4')lvcc = 2.708; ) 

/• •• Solve for the Pulse Width (TV) solution " •/ 
il(ms=»l) { CV=sel;RV=se2;sln=.32*RVCV'(l+.7/RV),TV=sln, } 
elseifi;ms=2) { CV=sel; RV=se2; sln-31'RV'CV'(I+l/RV), TV-sln, ) 
else lifnis = 3) { CV=sel,RV-se2;sln-.693*RV*CV, TV-sln; ) 
ekeif(ins = 4) ( CV=sel,RV=se2,sln=.28*RV*CV*(l+.7/RV);TV=sln; ) 
elseif(ms = 5) ( CV=sel;RV=se2;sln=.45*RV'CV; TV=sln; ) 
elseiffms — 6) ( CV=sel, RV=se2,sln= RV'CV; TV=sln, ) 

elseif(m5=7) { CV=sel,RV=se2,sln=2*RVCV*lvcc; TV=sln; ) 
else ifl;nis = 8) ( CV=sel, RV=se2;sln=l I'RVCV, TV=sln; ) 

/* *■ Solve for the Capacitance (CV) solution •• ■/ 
e!seiftms = 9) ( RV=sel;TV=se2, sln=3.125'TV/RV'(l+l/RV), CV=sta, ) 
elseill:ms=IO){ RV=sel,TV=se2;sln-3.22*TV/RV*(l+l/RV); CV=sln; ) 
else iftms = 1 1) { RV=sel ; TV=se2; sln=l ,443*TV/RV; CV=sln; > 
elseif!;ms=12)( RV=sel;TV»^e2; sln=3,57«TV/RV«(l+.7/RV), CV=sln; ) 
elseif|;ms— 13){ RV=sel,TV=se2; sln-2.22'TV/RV, CV=sln, ) 

eke iffms •= 1 4) { RV=se 1 , TV=se2, sln-TV/RV, C V=sln; ) 

else iHms = 1 5) ( RV=sel ; TV=se2; sln=5*TV/RV'lvcc; CV=sln; ) 
elsei((ms=16)( RV=sel;TV-se2;sln-.909-TV/RV, CV=sln, ) 

/• " Solve for the Resistance (RV) solution ■* "/ 

ekeifi;ms=I7){ TV=sel;CV=se2;sln=3.125'TV/CV; RV=5ln, ) 

elseifi:ms=18){ TV=seI,CV-se2;sln=3.226-TV/CV, RV-sln; ) 

elseifi;ms=19){ TV=sel,CV-se2,sln=1.443-TV/CV; RV=sln, ) 

else i^rns = 20) { TV=sel, CV=se2; sln=3.57*TV/CV; RV=sln; ) 

elseifl;ras = 21)( TV=sel;CV=se2;sln=2.22*TV/CV; RV=sln, ) 

else if(ms = 22) { TV=sel , CV=se2, sln=TV/CV; RV=sln; ) 

else ilfms = 23) ( TV-sel, CV=se2; sln=5*TV/CV»lvcc; RV=sln; ) 

else ilfms = 24) ( TV=sel ; CV=se2; sln=.909'TV/CV; RV=sln; ) 
> 

/• = Multiply input by scale factor = */ 
void sc8_par(mu!ti) /• From: mon calcO *^ 
char muJti; 
{ 

ifttoupper(multi) = 'S') { sen=sen*le+6; return, } 

else ifl;toupper(multi) = 'T) { scn^sen" I e+3; return; ) 

else if(toupper(multi) ^ 'U') { sen=sen*l; return; } 

elseifl;toupper(multi) = 'M') { sen=sen"I; return, } 

elseil(toupper(multi)^*N') { sen^sen^Ie-S, return; } 

elseifttoupper(multi)='P') { sen=sen*le-6, return; ) 

elseifi;toupper(multi)^^'0') { sen=sen*l; return; } 

elseif(toupper(multi)='K') { sen=$en*]e+ 3, return; } 

elseif(toupper(niulti) = 'L') { sen=sen* I e+6; return; } 

) 



/* = Request decision to continue or to exit. = '/ 

voidrepeatO /* From: moncalcO "^ 

{ 

char verify; 

printfl^' '\n\tDo you wish to continue with new input < Y/N>? : ' '); 

verify = getchO; 

ifttoupper(verify) = *N') exitQ, 

else printfC'%s",CLRSN); mainO; 
) 



Listing 1 . lite source code for MONO.C. 



1:/' 
2:1' 
1:1' 



'TIMRC**' 



**»»»»**»»» 



4: /* A program for calculation of 555/556 timer • 

5: /'variables. ••••*•••♦•••••••'*• •' 

6: /• by Clement S. Pepper * 

7: /• "' 



mm*»***mmmm»»»**f**»»*»i 



V 



9: (/include <stdio.h> 
10: 

11: /• == DEVICE-ANSI.SYS required in CONFIG.SYS = ' 
12: #define CLRSN '■\03312J" /* ANSI Clear the screen •/ 
13:#defineCURUP"\033lA" /* ANSI Cursor up one line •/ 
14; #define CURDN "WSSIB" /• ANSI Cursor down one col '/ 
15: ((define CURBK "\033[D" /'ANSI Cursor left one col •/ 
16: ((define CURLS "\033|K" /• ANSI Erase to line's end •/ 



17: ((define ERASE " " /• Erase one space 

18: 

19: /• ^^ fimction prototypes ^^ */ 

20; void mainO, eiTor_inO, astbl_prO, astblinO, 

21: y_n_verO, ast_calc(intjnt), repeatO, 

22: sca_par(int), equatn(int), ncw_ent(intjntjnt); 

23: 

24: /*= global variables ^="/ 



•/ 



25:intaj; /* xfer variable 2nd in */ 

26:intf^ = 0, /• 2nd entry flag */ 

27: float sln,Tr,DC,TC,RA,RB; /• solution variables '/ 
28: float sen, sel,se2, se3; /* known var's entered •/ 
29: 

30: /■ == astable solution message structure = •/ 
31: struct astcalc { 

32: char*eq_cde; /* This letter and */ 

char *p_stmg; /• this message together in */ 
char 'parm; /■ conceit relate this variable */ 
char*msg; /* to this solution for imknown ■/ 
char 'multi; /• Input parni multipber. */ 

) astable[8] = ( 
"A'\ "one-cycle time", "TT", 
"uSec is the solution for one period.", 
" S=seconds : T=mS : U-uS : ", 
"B", "duty cycle (must be <.33)", "DC", 
"is the solution for the duty cycle.", 
" - No multiplier for DC. Press RETURN", 
"C", "timing capacitor", "TC", 
"MFD is the timing capacitor solution", 
"M=mfd:N=nfd:P=pfd:", 
"D", "upper resistor", "RA", 
"OHMS is the upper resistance solution.", 
" 0=Ohms : K^Kohms : L=Mohms : ", 
"E", "lower resistor", "RB", 
"OHMS is the lower resistance solution.", 
" 0=Ohms : K=lCohms : L=Mohms : ", 
"D", "upper resistor", "RA", 
"OHMS is the upper resistance solution.", 
" 0=Ohms : K=Kohms : L=Mohms : ", 
"E", "lower resistor", "RB", 
"OHMS is the lower resistance solution", 
" 0=Ohms : K=Kohms : L=Mohms : ", 
"E", "lower resistor", "RB", 
"OHMS is the lower resistance solution.", 
" OK)hms : lC=Kohms : L^Mohms : " ); 



33: 

34: 

35: 

36: 

37: 

38: 

39: 

40: 

41: 

42: 

43: 

44: 

45: 

46: 

47: 

48: 

49: 

50: 

51: 

52: 

53: 

54: 

55: 

56: 

57' 

58: 

59: 

60: 

61: 

62: 

63: /* =^ Begin Program = ■/ 

64: void mainQ 

65: { 

66: pnntH"%s",CLRSN), /• clear the screen '/ 

67: printf("\tHii Pick two variables for solution fi-om the 

table below.\n' '); 
68: printfl^"\tEnter Uiem in ascending order (b e, not e b) \n"), 
69; printf("\tFollow each with a RETURN:\n\n"); 
70; printft"\t A - ONE CYCLE TIME, TT. TT - tOow)+t(high).\n"); 
71: printfl:"\t B = THE DUTY CYCLE, DC. DC = tOow)m^n"); 
72: printR' nt C = THE TIMING CAPACITANCE, TC.\n' '), 
73: pnntl("\t D = THE UPPER RESISTANCE, RA.\n' '), 
74: printf("\t E - THE LOWER RESISTANCE, RB.\n\n"); 
75; printf(' '\tNote: Do not select A and C as a pair.\n' '); 
76: pTinti("\tAn entry is not a committment till you make it so.\n"), 
77: prin1fl^"\tlf you flub, just continue on, till queried.\n"); 
78: printfl;"\tThen enter N to start over.Vn"), 
79; astblinO; 



•/ 



81; 

82; /* = erroneous input selection message = 

83: void error_inO /" from astblinO */ 

84: { 

85: printf("\n\tYour entry, %c, is outside the menu.\n",astable|aj].eq_cde); 

86: printf("\t Please re-enter your selection,\n"); 

87; astblinO; 

88;) 

89: 

90: /* = defining astable parameters ^ •/ 

9 1 : void astbl_piO /• fi-om astblinO *' 

92: { 

93:intastl,ast2, 



94: 
95: 
96: 
97: 
98: 
99: 



iPg=0)astl ■ 
else ast2 = aj; 



aj; 



iltflg = 0)(flg= I; astblinO;) 
ifl:flg=l)flg = 0; 



100: printf("\tAre %s and %s what you want? <y/N> :",astable|astl].eq_cde,\ 



astable|ast2).eq_cde); 
printl("\n"); 
y_n_verO; 
a5t_caic(astl,a5t2); 



101: 

102: 

103: 

104: 

105:) 

106: 

107: /* ^ read keyboard inputs = */ 

108: /• 6om mainO, etiorinO, astbl_prO, y_n_veiO, ast caIcO */ 

109: void astblinO 

110: ( 

HI: char sel, scanf(' ■%c",&sel); aiush(stdin); 

112: switch(toupper(sel)) { 

113: case * A' : aj = 0; astbl_pi(); 

114: case 'B': aj= I;astbI_piO; 

115: case'C: aj = 2;astbl_pi(); 

116: case'D': aj = 3; astbljjrQ; 

117: case'E': aj = 4;astblj)rO; 

1 18: default: printfl;"%s%s%s%s",CURUP,CURBK,ERASE,CURBK); 

1 19: crTor_inO; 
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120: 

121: 

122: 

123: 

124: 

125: 

126: 

127: 

128: 

129: 

130: 

13! 

132: 

133: 

134: 

135: 

136: 

137: 

138: 

139: 

140: 

141 

142: 

143: 

144: 

145: 

146: 

147: 

148: 

149: 

150: 

151 

152, 

153: 

154: 

155: 

156: 

157: 

158: 

159: 

160: 

161 

162: 

163: 

164: 

165: 

166: 

167: 

168: 

169: 

170: 

171: 

172: 

173: 

174: 

175: 

176: 

177: 

178: 

179: 

180 

18! 

182 

183: 

184: 

185: 

186: 

187: 

188: 

189: 

190: 

191: 

192: 

193: 

194: 

195: 

196: 

197: 

198: 

199: 

200: 

201 

202: 

203: 

204: 

205: 

206: 

207: 

208: 

209: 

210: 

211 

212 

213: 

214 

215 



/* ^= verify selection entry = */ 

void y_n_verO /* from astbljjri) •/ 

{ 

char verify; 

verify = getchO, 

if(touppei<verify) ^ ' Y') return; 
else( 

printfi;"%s%s%s%s%s",CURBK,CURUP,CURUP,CURUP,CURUP); 

printf("%s\n%s\n%s\n%s\n",CURLS,CURLS,CURLS,CURLS); 

printfi;"%s%s«/«s%s%s",CURBK,CURUP,CURUP,CURUP,CURUP), 

pimtfl;"\t Please re-enter your selections .\n"); 



flg = 

) 



0; astblinO; 



/* = perfoim calculations = •/ 

void ast_calc(nl^2) /• from astbl_prO */ 

intnl,n2, 

( 

char scale, sfl,sf2; 

int ml, m2, m3, msl, ms2; 



if(nl» 
else if(nl 
printft' 
printfl;' 
else iftnl 
elseifl^nl 
elseiUnl 
elsei^nl 
elseifl^nl 
else if(nl 
else iftnl 
else il(nl 



&& n2 = 1) { ml=2; m2-3; m3=4; m5l=0; ms2=l ; ) 

= 0&&n2 = 2){ 
AtThere is no unique solution for this combinationAn"); 
\tPlease re-enter your selectionsAn"); astblinO; } 



= && n2 = 3) ( ml=l , m2=2, ni3=4, nisl=3, ms2=0; 
= &A n2 ~ 4) ( ml=l ; m2=2; m3=3; nisl=4; ms2=0; 
= 1 &<&n2 = 2) { ml=0; m2=3; m3=4, msl=2; ms2=l 
= 1 && n2 = 3) { ml=0; m2=2; in>4; msl=5; ms2=l 
= 1 &&.n2 = 4) {inl=0;m2=2;m3=3;msl=7;ms2=l: 
= 2 && n2 = 3) ( ml=<); m2=l, m3=4; nisl=3; nis2=2 
= 2 && n2 = 4) { nll=0, m2=l , rn3=3; msl=4, ms2-2 
= 3 && n2 = 4) { ml-0; m2-l, m3-2, msl-6; ms2-3: 



/* ** First parameter entry. ** */ 

printfi;"Enter your %s requirement %s: ",astable[ml].p_stmg,\ 
astable[mll.parm); 
scanfi;"%f ',&sel); fBush(stdiii), 
printfC* Enter multiplier %5 ",astablelml].multi); 
scanf("%c",&scale); fflush(stdm); 

sen = sel; sca_par^scale); sel =sen; 

/• ** Second parameter entry. •• */ 

printH"Enter your %s requirement %&: ",astable[m2].p_sting,\ 
astable[m2].parm), 
scanfi;"%f ',&se2); fflush(stdin), 

printf("Enter multiplier %s ",astable[m2].multi); 
scanf("%c",&scale); fHush(stdin), 
sen = se2, sca_par(scale); se2 = sen; 



/* ** Third parameter entiy. •* */ 
printfi;"Enter yotu %s requirement %5: 
astablefmSJ.parm), 

scanfl;"%f,tee3); fflush(stdin); 



,aslable[rTr31.p_stmg,\ 



ptintf('*Enter multiplier %s ",astable[m3) multi); 
scanli;"%c",&scale); fDush(stdin); 
sen = se3; sca_par(scale); se3 = sen, 

iHnl = && n2 = 1) { TC-sel,RA-se2;RB=se3, ) 
else iHnl = && n2 = 3) { DC-sel ;TC=se2,RB=se3, ) 
else iftnl — && n2 = 4) { DC=sel ,TC=se2,RA=se3, ) 
else iftnl — 1 && n2 = 2) ( TT-sel;RA=se2;RB-se3, ) 
eUe iffnl = 1 && n2 — 3) { TT=sel ;TC=se2;RB-se3, ) 
else iftnl = 1 &A n2 — 4) { TT=sel ,TC=se2;RA-se3; ) 
else itCnl = 2 && n2 = 3) ( TT=sel;DC=se2,RB=se3; ) 
else iftnl = 2 &&. n2 = 4) ( TT=sel;DC=se2,RA=se3, ) 
else iHnl = 3 && n2 = 4) ( TT=sel ;DC=se2;TC=se3, ) 



/* ** display solutions ■* */ 

equatn(msl); 

ptintfi;"\t*/os = %.3g%s\n",as1able[msl]-parm,sln,astable[msI].msg); 

equatit(ms2); 

pnntft"\t%s = %.3g %s\n",astable[ms2].parm,sln,astable(ffls2]-msg); 

printll;"\t%s = %.3g : %s = %.3g : %s = %.3g \n",astabk(ml).parm,sel,\ 
aslable|m2).parm,se2,astablelm31.parm,se3); 

/ ERROR MESSAGES / 

ifi:DC > .333) { 
pnntfl;"\t"" DC must be less than 0.333. ""\n"), 
new ent(ml,m2,m3); ) 

if(Tr<0 II DC<0 II TC<0 (1 RA<0 || RB<0) ( 

printfl^'At*** Negative values for any parameter not acceptable. ***\n"); 
new_ent(ml,m2,ni3); ) 

printH"\n\tn)o you wrsh to continue with new input <Y/N>?"), 



216 
217 
218: 
219: 
220: 
221 
222 
223: 
224: 
225: 
226: 
227: 
228: 
229: 
230: 
231 
232: 
233: 
234: 
235: 
236: 
237: 
238: 
239: 
240: 
241 
242: 
243: 
244: 
245: 
246: 
247: 
248: 
249: 
250: 
251 
252: 
253: 
254 
255: 
256: 
257: 
258: 
259: 
260: 
261: 
262: 
263: 
264: 
265: 



repeatO; 



/* = repeat option = */ 

void repeatO /* from ast_calcO */ 

( 

char verify; 
verify = getchO; 

if(toupper(verify) = 'N") exitO, 
mainO; 
) 

/• ^== parameter scalii^ ^^ •/ 

void sca_par(niuiti) /* from astcalcQ •/ 

char multi; 

{ 

ifi;toupper(muIti) = 'S') { sen = sen''le-t-6; return; } 
eUeifl;toupper(multi) = T') ( sen = sen*le+3; return; } 
else !fi;toupper(multi) = 'U') ( sen = sen* 1 ; return; ) 

elseifl|toupper(multi)= 'M') { sen = sen*l; return; } 
else if(toupper(multi) == 'N') { sen = sen* le-3, return, } 
else if(toupper(muIti) = 'P') { sen = sen*le-6; return; } 

else ifl;toupper(mu]ti) = 'O') { sen = sen* U return; } 
el5eif(toupper(multi)='K*) { sen = sen*le+3, return, ) 
elseif(toupper(multi)='L') {sen = 5en*le^-6; return; } 
) 

/* = solution calculations = "I 
void equatn(eqn) /* from astcalcQ "/ 
int eqn; 



if(eqn= ) { sin ^ 
if(eqn= 1 ) { sin = 
ifl;eqn= 2 ) { sin = 
ifi^eqn= 3 ) { sin = 
if(eqn= 4 ) { sin - 
ifi;eqn= 5 ) { sin = 
if(eqn= 6 ) { sin = 
iii;eqn= 7 ) { sin ^ 
} 



.693*(RA+2*RB)*TC; 
RB/{RA+2*RB); 
l,443*n7(RA+2*RB); 
RB*(1-2*DCVDC; 

DC*RA/(1-2'DC); 



TT= sin, return;) 
DC = sin; return, ) 

TC = sin; return; } 
RA = sin; return; } 
RB = sin; return; ) 



(TT-l .368*RB*TC)/(.693'TC), RA = sin; rehim; } 
TT*DC/(,693*TC); RB = sin, rehim, ) 

aT-.693*RA"TC)/(1.386*TC); RB = sin; return, } 



/* = new parameter selections = */ 

void new_ent(ml jn2/n3) /• from ast_calcO */ 

intmi,m2,m3; 

{ 

printH' '\tSelect new values for %s, %s, and %s for calculation-\n' ' ,\ 
astable|ml].parm,astable[m2].parm,astable[rTi3].parm); 



Listing. 2. The source code forTlMR.C. 



IC MONO EQUATIONS AND VARIABLES USED IN MONO.C 



PROGRAM VARIABLES 
MENU MONO EQUATIONS mdims ml m2 m3 



A 9600 



B 9601 



R = 3.125'T/C*(l+.7/R) 17 1 2 

T=.32*R"C"(l+07/R) 112 

C = 3.125'T/(R'(l+.7/R))0 9 2 1 

R = 3.125*T/C*(l+.7/R) 1 17 1 2 

T = .32'R'C*(l+0.7/R) 1112 

C = 3.125'T/(R'(l+.7/R) 19 2 1 

R = 3.226"T/C*(1+1/R) 2 18 1 2 

T=.3rR'C*(l+l/R) 2 2 12 

C = 3.22T/R'(1+1/R) 2 10 2 1 



R-1.443*T/C 
T=.693'R*C 
C=1.443*T/R 



3 19 1 2 
3 3 12 
3 112 I 



E 74122 R = 3125*T/C'(l+.7/R) 4 17 1 2 

T=.32»R'C'(l+.7/R) 4 112 

C = 3.125'T/R'(l+.7/R) 4 9 2 1 

F 74123 R = 3.57'T/C'(l+.7/R) 5 20 1 2 

T=.2g*R*C*(l+7/R) 5 4 12 

C = 3.57r/R'(l+.7/R) 5 12 2 1 



G74LS123 R = 2.22*T/C 
T=.45'R'C 
C = 2 22*T/R 



H 74221 



I74LS221 



R=1.443'T/C 
T=.693'R'C 
C-1.443'T/R 
R=1.443*T/C 
T=.693*R*C 
C-1.443'T/R 



6 21 1 2 

6 5 12 

6 13 2 1 

7 19 1 2 
7 3 12 

7 11 2 1 

8 19 1 2 
8 3 12 
8 11 2 1 



SOURCE/LIMITS 



Fairchild 
R: 5 - 25K 
C:ANY 

National 
R:5-25K 
C:ANY 

National 
R: 5 - 25K 
C:ANY 

Texas Inst. 
R: 1,4-40K 
C:ANY 

Texas Inst. 
R: 5 - 50K 
C:ANY 

Texas hist. 
R: 5 - 50K 
C:ANY 

Texas Inst. 
R: 5 - 50K 
C:ANY 

Texas Inst. 
R: 2 - 40K 
C: 1000 MFD 
Texas Inst. 
R: 2 - lOOK 
C: 1000 MFD 
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J74C221 R-T/C 
T-R'C 
C-T/R 
also the 4538 Motorola, RCA 



K 4528 R = 5T/(C*0nVcc)) 
T=.2»R*C*0nVcc) 
C = 5*T/R*0n Vcc) 

In 5=1.61 
In 10 = 2 30 
In 12 = 2 48 

In 15 = 2.71 

L 555/556 Pulse High Tane: 
R-.909*T/C 
T=1.1'R*C 
C - .909"T/R 



9 22 1 2 
9 6 12 
14 2 1 



10 23 1 2 
10 7 1 2 
10 15 2 1 



National 
R:ANY 
C:ANY 



MotoroKRCA 

R:5K-1M 

CANY 



1124 1 2 
11 8 1 2 
11 16 2 1 



Signetics 
R:ANY 
C;ANY 



Note: Souices shown are for reference; each monostable type is typically 
available from several sources. 



Table 1 . Monostable equations as employed in MONO.C. 



The below reprint is from National Semiconductor Linear 
Databook. It is application information typical of manufactures 
specifications used to calculate timer values. 



555/556 ASTABLE TIMER EQUATIONS 

Period: TT = .693*(RA+2*RB)*TC 

Duty Cycle: DC = RB/(RA+2'RB) 

Timing Capacitor:.... TC = 1.443'n/(RA+2*RB) 

Upper Resistor RAl = (TT-1 .368'RB'TC)/(.693*TC) 

or RA2 = RB*(1-2DC)/DC 

Lower Resistor: RBI -DC*RA/(1-2*DC) 

or RB2 = rr Da(.693*TC) 

or RB3 = (Tr-.693*RA*C)/(1.386'C) 

The resistance equations to be used depend on data input 
and the sequence in which calculations are made. This is 
seen in the table below. 

MENU SOLVE PROGRAM VARIABLE ASSIGNMENTS 
SEL'NSFOR nln2mlm2in3 msl ms2 

A,B TF.DC 12 3 4 (XJV) l(DC) 

A,C 

A,D TT.RA 3 12 4 3(RA2)0(Tr) 

A,E TT,RB 4 12 3 4(RB1)0CI10 

B,C DCJC 12 3 4 2{TC) 1(DC) 

B,D DC,RA 13 2 4 5(RAI) l(DC) 

B,E DC,RB 14 2 3 7(RB3) 1(DC) 

C,D TC,RA 2 3 14 3(RB2) 2(TC) 

C,E TC,RB 2 4 13 4(RB1)2(TC) 

D,E RA,RB 3 4 12 6(RB2) XRA2) 



Table 2. 555/556 timer IC equations and variable assignments 
asusedinXIMR.C. 



TC RA RB 

DC TC RB 
DCTC RA 
TTRA RB 
rr TC RB 
TT TC RA 
TT TC RB 
TT DC RA 
TT TC DC 
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FORTH MULTITASKING IN A NUTSHELL 

By Brad Rodriguez 



Multitasking in Forth is veiy simple, incredibly powerful. .and 
widely misunderstood. This talk will describe what multitasking 
can do, and when it can be profitably used. The most conmion 
Forth multitasker - the cooperative, roimd-robin model ~ will 
be explored in general terms. Example code will be given for 
F83, which will be used to illustrate how to create and control 
parallel tasks, protect shared resources with semaphores, and 
pass messages between tasks. Preemptive and prioritized multi- 
taskers will be mentioned briefly. 

INTRODUCTION 

What is multitasking? 

Multitasking is the ability to run several independent programs 
in a single CPU, apparently simultaneously. Of course, a 
single CPU can only run one instruction at a time. The illusion 
is created by switching the CPU very quickly -- hundreds of 
times a second ~ among several different programs. Each of 
these programs is called a "task," hence the name 
"multitasking." 

A popular fallacy is that you need a big CPU, like a 68000, in 
order to do multitasking. This is simply not true, Any CPU 
can multitask; I've done it on ZSOs and single-chip ZSs. 

Another fallacy is that you need a real-time clock interrupt to 
"time sUce" the tasks. While some multitaskers do indeed 
work this way, the Forth multitasker does not. You can 
multitask without interrupts, and with no special hardware 
support at all! 

It is important to distinguish between multitasking and 
multiuser . Multiuser systems are those that support multiple 
terminals, and give several people the illusion of working each 
on his own computer. Multitasking is simpler: there is only 
one user, but he can have several things running simulta- 
neously. Unix is multiuser. Amigas, Macintoshes, and Win- 
dows PCs are multitasking. 

Occasionally, in a computer science text, you will see 
muUitasking called multiprocessing . 1 prefer to avoid this 
usage. To me, multiprocessing means several CPUs operating 
in parallel. If it's on a single CPU, 1 call it multitasking. 



When should multitasking be used? 

There are several situations ~ some more obvious than others 
~ which can benefit from multitasking. 

Parallel operations. Some computer applications just naturally 
have several things running at once. An embedded process 
controller probably has to keep the control loops running, even 
while the operator is typing commands on the keypad. Net- 
work communications generally have to be maintained while 
other things are going on. And usually you'd like to be able 
to do something else while the printer is grinding out a long 
listing. All of these are candidates for multitasking. 

Using idle time. Many computer programs spend a lot of time 
waiting ~ maybe for a keypress, an external event, or a data 
transfer to complete. Sitting in a wait loop is a waste of good 
CPU time! Multitasking allows the CPU to be doing some- 
thing else while waiting for an event. 

Coroutines. Sometimes you need to break out of a program ' ' in 
the middle." For example, 1 recently wrote a command pro- 
cessor which needed to stop and wait for a keypress at a deeply 
nested level. Multitasking allows a program to be suspended 
at any point , and later resumed, with no special effort on the 
part of the programmer. 

Clarity and ease of programming. Often a program is easier 
to write, and its logic is more obvious, if you use the facilities 
that a multitasker gives you. Sometimes an algorithm is best 
expressed procedurally, in terms of waiting for an event ~ even 
when you know the CPU can't just sit there and wait. I could 
have written the command processor using a huge state table, 
and entered the routine "at the top" on every keypress ~ but 
it would have been much larger, and impossible to read and 
maintain. Multitasking adds WAIT and PAUSE to your 
' 'programming toolbox. ' ' You just use them naturally, and the 
multitasker takes care of the details. 

HOW FORTH MULTITASKING WORKS "INSIDE" 

What each task requires 

What is needed to support multiple Forth tasks? 

Separate programs. In most multitasking applications, each 
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task will run a different program. In single-user Forth systems, 
these need not be in separate dictionaries; they can simply be 
Forth words with different names. 

In multiuser Forth systems, several people may be adding 
definitions at the same time. So, each user needs some RAM 
for a private dictionary. F83 does this. (How multiple dictio- 
naries are managed, and linked to the "main" Forth dictio- 
nary, are beyond the scope of this article.) 

Re-entrant kernel code. We'd really prefer not to have a 
separate copy of DUP or FIND for each task! Code which can 
be shared by several tasks simultaneously is called "re-en- 
trant." Among other things, re-entrant code can't leave im- 
portant data in global variables. Fortunately, Forth code, with 
its use of stacks, tends to be naturally re-entrant, and the 
"cooperative" multitasker relaxes some of the restrictions on 
temporary variables. Most Forth kernels are fully re-entrant. 

Private stacks. Obviously, each independent Forth program 
will need its own parameter and return stacks. So, each task 
has some RAM for its stacks, and also has its own parameter 
and return Stack Pointers. 

Private "user areas." Some things simply must be kept in 
variables, and yet will have different values for each task. The 
"bottom" stack addresses SO and RO are two examples; the 
BASE for number conversion is another. So, each task needs 
a private RAM area for variables, called the user area . Differ- 
ent Forth kernels may keep fi"om six to several dozen variables 
in the user area. Most Forths provide a ' 'user variable' ' which, 
instead of returning an absolute address, indexes into the user 
area of whichever task is currently running. 

The user area is essential to hold certain task control data: 
among other things, the ' 'saved' ' stack pointer, and the link to 
the next task. Both of these will be discussed shortly. 

Private buffers. Certain buffers must exist privately for each 
task. One example is the PAD buffer which is used for numeric 
output. If two tasks tried to display a number at the same time, 
using a single PAD, nonsense would result! Such buffers may 
be kept in the user area, or (in multiuser systems) in the private 
dictionary. 

Multiuser systems also need separate Terminal Input Buffers. 
Usually, though, a single set of disk buffers is shared by all the 
tasks. 

Switching tasks 

Most Forth systems use the simplest of multitasking schemes: 
the "round-robin, cooperative" multitasker. Round-robin 
means that each task takes its turn at the CPU, one at a time, 
in a fixed sequence ~ a big loop of tasks. Cooperative means 
that each task has the CPU as long as it wants, and releases the 
CPU only when it's ready - nothing will "grab" the CPU 
away from a task. 



Figure 1 shows the RAM allocation for a three-task Forth 
system. The private areas described above are usually grouped 
together for convenience. The dictionary and the disk buffers 
are common to all of the tasks. 

Switching from one task to another — that is, from one program 
to another ~ requires three steps, 

a) Save the state of the current program. Everything necessary 
to restore this program - to exactly the point where it was 
suspended - must be saved. This is called the ' 'task context, ' ' 
and may include the CPU's program counter, flags, and reg- 
isters, as well as data in RAM. 

In Forth, most of the task context is on the (private) parameter 
and return stacks, and so is safe from alteration. But there are 
four crucial values which are so frequently used that they are 
usually kept in CPU registers: 

SP - the parameter Stack Pointer 

RP - the Return stack Pointer 

IP - the Interpreter Pointer 

UP - the User Pointer (base address of the user area) 

These four registers must be saved and restored when the task 
is switched, (ft turns out that we don't need to save the CPU's 
Program Counter, since we never change tasks in the middle 
of a CODE word.) 

b) Select the next task to run. This may be done in fixed 
rotation, or according to some priority scheme. 

c) Restart the new task according to its saved context. This will 
resume execution of the new task at the point where it was last 
suspended. 

The task switch in F83 

The Forth word which switches tasks is traditionally called 
PAUSE. It must do the following: 

a) Save the IP, RP, and SP. Typically two of these will be 
pushed on a stack, and that stack's pointer will then be saved 
in the user area. We don't need to save UP; you'll see why in 
a moment. 

b) Get the address of the next task's user area. This is what 
the LINK variable in the user area is for: it contains the address 
of the next task in the round-robin sequence. (The tasks are 
thus chained together in a linked list.) Note that this link gives 
you the UP (user area address) for the new task! This is why 
UP doesn't need to be explicitly saved. 

c) Restore the IP, RP, and SP of the new task. 

d) Continue Forth execution! 
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The time it takes to do this is called the ' 'context switch time, ' ' 
and is an important figure of merit for multitasking systems. 
Since Forth systems only have to save three CPU registers, 
their context switching times are quite fast ~ under 10 micro- 
seconds on some 8-bit CPUs! 

F83 on the IBM PC uses some tricks to improve performance. 
(Refer to Figure 1 .) In F83, step (b) is performed by jumping 
into the next task's user area. In this area is a code fragment 
(INT 80h) which executes a RESTART routine. This RE- 
START routine does the step (c) described above. 

Why does F83 do this? A task which is not ready to run can 
be "put to sleep" by changing the INT 80h to a JMP instruc- 
tion. Then, when PAUSE jumps to this task, it immediately 
jumps to the next task. The sleeping task is skipped in only one 
machine instruction! 

You can see that if all the tasks had JMP instructions, the 
round-robin loop would be simply a loop of jumps. Of course, 
the CPU would then be stuck in an infinite loop! Usually, 
several tasks will be "awake" with INT 80h instructions. 

F83's PAUSE and RESTART are coded as follows: 

CODE (PAUSE) 

IP PUSH save IP on parameter stack 

RP PUSH save RP on parameter stack 

UP #) BX MOV SP [BX] MOV save SP in user area 

BX INC BX INC BX INC BX INC calculate address of next 

[BX] BX ADD BX INC BX INC task from (relative) LINK, 

BX JMP C; then jump to that task 



CODE RESTART 

-4 # AX MOV 

BX POP 

AX BX ADD 

BX UP #) MOV 

AX POP AX POP 

STI 

[BX] SP MOV 

CLI 

RP POP 

IP POP 

NEXT C; 



entered from an INT 80h instruction 

get return adrs saved by INT 80h 
adjust it to the start of user area 
make this the current UP 
clean up INT 80h leftovers 

restore SP from user area 

restore RP from parameter stack 
restore IP from parameter stack 
continue Forth execution at new IP 



USING A FORTH MULTITASKER 

Creating a task 

All Forth systems start with one task, (There's always at least 
one program running!) New tasks can then be added to the 
system in two phases, which I call creation and activation . 

Creating a new task involves two steps: 

a) Reserve RAM for the task. Space must be allocated for its 
two stacks and its user area. In multiuser systems, a private 
dictionary must be reserved as well. 

b) Link the task into the round-robin list. This is a simple 



linked-list insertion using the LINK field. 

These steps are performed only once. Obviously, reserving 
RAM twice for the same task is a pointless waste of RAM.. and 
can lead to confiision if other tasks need to know where this 
task is located. Linking the task into the list twice is more 
subtle, and more insidious: usually it ends up destroying the 
round-robin loop! 

In F83 on the IBM PC, steps (a) and (b) are performed by the 
word TASK:. This word expects, on the stack, the number of 
bytes to reserve for the new task. 256 bytes are reserved for the 
return stack, and the rest is divided between the user variables, 
the private dictionary, and the parameter stack. Thus: 

HEX 400 TASK: SCREEN-CLOCK 

defines a task and allocates a total of 1024 bytes to it. The 
newly defined word SCREEN-CLOCK will return the base 
address of this 1024-byte area (the base address of the user 
area). 



Activating a task 

Once the task has been created, it can be 
number of times. This involves two steps: 



'activated" any 



c) Initialize the task context. Several user variables must be 
initialized, and in F83 the INT 80h instruction must be inserted 
in the user area. Also, the initial values for the SP and RP must 
be stored in the stacks or user area in such a way that they will 
be correctly loaded into the CPU registers when this task is 
"resumed" for the first time. 

d) Specify the code to be executed by that task. The inirial 
value for the IP must be stored in the stacks or user area, too. 
When the task is "resumed" for the first rime, this will be 
where execution begins. It must point to a Iragment of high- 
level Forth code. 

(Some Forths may only perform step (c) once, in which case it 
may be done as part of task creation.) 

After the task has been activated, it will lie dormant until its 
turn in the round-robin loop. Then it will begin execuring the 
Forth code specified in step (d). 

In F83, the RP, SP, and IP are initialized by the word ACTI- 
VATE. F83 's ACTIVATE must be used within a Forth word 
~ it caimot be used interpretively. It expects the address of the 
task on the stack, and is immediately followed by the high-level 
code the new task is to run . For example: 



START-CLOCK SCREEN-CLOCK ACTIVATE 



code performed by "main" task 



BEGIN CLOCK PAUSE AGAIN ; 
< > 

code performed by 
SCREEN-CLOCK task 
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START-CLOCK is executed by some other Forth task -- 
typically the "main" (initial) task. It then "activates" the 
SCREEN-CLOCK task to perform the code fragment BEGIN 
.CLOCK PAUSE AGAIN. The main task exits this word 
immediately after ACTIVATE. 

Other task control in F83 

The functions described above ~ PAUSE, TASK:, and ACTI- 
VATE ~ are all that you need to establish a multitasking Forth 
system. But F83 provides some additional words for conve- 
nience: 



a task is created, it is linked into the round-robin list. If you 
- accidentally or intentionally ~ reclaim a task's RAM area 
with FORGET, and then put other definitions into that RAM, 
you will destroy the round-robin linked list! (Again, boom.) 
It's safest to put all the task creation first in your code, and then 
never FORGET back that far. 

Example #1: the on-screen clock 

Note: the example code given in this article is written for F83 
version 2.1.0 for the IBM PC. F83.COM seems to be distrib- 
uted with the multitasker already installed. Type 



taskaddr SLEEP puts a task to sleep, by inserting the JMP 
instruction in the user area. 

taskaddr WAKE awakens a task, by inserting the INT 80h 
instruction. 

STOP just puts the running task to sleep, and then switches 
to the next task. This is equivalent to my-task SLEEP 
PAUSE 

MULTI enables the multitasker. 

SINGLE disables the multitasker, by changing the action of 
PAUSE to a "no-op." (PAUSE is a DEFERred word for just 
this purpose.) Whichever task does SINGLE will keep control 
of the CPU. 

APPLYING THE FORTH MULTITASKER 



The PAUSE : running programs in parallel 

The simplest use of a multitasker is to have several programs 
running in parallel. This requires only that every program 
have its own task, and that every program obey two rules: 

a) Every task must PAUSE periodically! This is how the task 
voluntarily surrenders the CPU to the other tasks in the system. 
If there are no PAUSEs, this task will never release the CPU, 
and no other task will ever run! 

Most Forth 1/0 words, such as EMIT, KEY, and BLOCK, 
contain a PAUSE. The assumption here is that I/O is slow, and 
so other tasks should have some time at the CPU. 

b) The code executed by the new task must never return! 
Remember, this code was not entered from a subroutine call ~ 
it is the very first code executed by this task. Thus, there is no 
return information on the return stack! (Boom.) In general, 
the ' 'topmost' ' Forth code of any task must be an endless loop. 
In F83, the word STOP can be used to end a task, instead of 
looping. 

There is also a rule for Forth programmers during the test and 
development phase: do not FORGET tasks! Remember, once 



' TASK: . 

to find out. If TASK: is not defined, you will need to install 
the multitasker by typing 

OPEN CPU8086.BLK 21 LOAD OPEN UTILITY.BLK 
52 LOAD 

Screen 1 of the lisUng is the code for a simple on-screen clock. 
This code creates a second task which confinually displays the 
time of day in the upper right-hand comer of the screen. 

@TIME is a Forth word to return the IBM PC clock time. 

We want to use the Forth display words, but we don't want the 
clock task to interfere with the main task's display. After we 
reposition the cursor to the top right of the screen, we need to 
be able to put it back where it was. The words @CURS and 
!CURS invoke BIOS functions to get and set the current 
display cursor. 

.TIME displays the time in hh:mm:ss format, ft illustrates the 
use of @CURS and ! CURS to get the cursor position, set a new 
position, and restore the original position. Note the use of 
SINGLE and MULTI around TYPE. TYPE does many 
EMITS, and each EMIT does a PAUSE. This would switch 
back to the main task while the cursor is in the wrong position! 
Rather than redefine EMIT to eliminate the PAUSE, we can 
simply shut off multitasking for the duration of the TYPE. 
(This is, however, quite crude.) 

The definition and activation of the SCREEN-CLOCK task 
have already been described. Note that you must specify 
DECIMAL from within the clock task's code. The number 
base is a user variable, and typing DECIMAL from the key- 
board will change the main task's number base, not the clock 
task's. 

After loading this screen, type 

START-CLOCK MULTI 
to activate the clock. You will see the clock appear in the 
comer of the screen. Type WORDS and observe that the 
displays do not interfere with each other. Then type SINGLE 
WORDS and compare the speed when the multitasker is 
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switched off. The clock display in this example consumes far 
too much CPU time; it redisplays the clock dozens of times 
every second, when only once per second would be adequate. 
A better version would wait for the time to change before 
redisplaying. 

Example #2: the round-robin cycle counter 

Screen 2 is Forth code to count passes through the round-robin 
list. Similar code is supplied as an example with F83 ; this code 
is different only in that it displays the cycle count in the upper 
right comer. Load this screen, and type 

START-COUNTER 

to activate the counter. (You may have to turn MULTI back 
on.) On my 12 MHz AT, with the on-screen clock task also 
running, 1 see about 50 counts per second. This means that 
each task is getting the CPU every 20 milliseconds. 

Waiting without pain 

Programmers seem to write a lot of wait loops. Most wait loops 
fall into one of three categories: 

a) polling an I/O device. Sometimes you must use polled I/O. 
The hardware may not have a "data ready" interrupt. Oper- 
ating system software may only offer a ' 'check status" function 
- such as the keyboard under MS-DOS. 

b) awaiting an interrupt. When the hardware supports inter- 
rupts, you may have to wait for an interrupt to occur. For 
example, a disk controller using DMA will issue an "end of 
transfer" interrupt when the operation is complete. 

c) waiting for another task. In multitasking applications, 
occasionally one task has to wait until another task has accom- 
plished something. 

Sometimes, waiting is just the obvious way to write a program! 
Recall the example of the command processor, which has to 
wait for a keypress to be received and processed. 

Wait loops burn up CPU time. Even worse, trying to wait for 
more than one thing at a time can lead to some Byzantine 
compound loops! A multitaskcr solves both of these problems. 

One simple addition changes the wait loop from a CPU hog to 
an efficient programming construct. SimpW insert a PA\]S£ 
in the loop! This ensures that, while this task is waiting, all 
the other tasks in the system will get to use some CPU time. 

Most multitasking Forth kernels write their I/O this way. For 
example, the basic definition of KEY 

: (KEY) BEGIN (KEY?) UNTIL 8 BDOS ; 

is changed in F83 to 



(KEY) BEGIN PAUSE (KEY?) UNTIL 8 



BDOS 



As long as no keypress is ready, this task will PAUSE repeat- 
edly, surrendering the CPU to the other tasks in the system. 
The polling represents a slight overhead: on every pass through 
the task list ~ typically every few milliseconds - this task will 
execute PAUSE (KEY?) UNTIL. If (KEY?) is not too 
complex, this overhead is negligible. 

Note that, even if a keypress is ready, the word (KEY) will do 
at least one PAUSE. This is usually desirable. If this is not 
desirable, a BEGIN.. WHILE..REPEAT loop can be used 
instead. 

What if all of the tasks are waiting for something? Then the 
system ends up spinning in a much larger wait loop - checking 
each task in turn for its "wake up" condition, and moving on 
to the next. The first task whose poll is successfiil will then 
continue execution. With no special programming effort, the 
multitasker automatically checks a set of events, and starts a 
different program for each event! 

Be aware that putting a PAUSE in the loop will significantly 
reduce the polling rate - from microseconds to milliseconds, 
ff fast response is essential, or there is a chance that an event 
can be "missed," some other approach is needed. Interrupts 
are usually best in this case. 

Shared resources and semaphores 

The problem of mutual exclusion 

Once you have several tasks running in parallel, a new problem 
can arise: access conflicts. This happens when two tasks 
attempt to use, simultaneously, some device or resource which 
can only be used by one task at a time. 

Consider, for instance, a disk controller which requires two 
time-consuming operations to access the disk: a seek, and then 
a read or write. (Many controllers are like this; the Western 
Digital 1791 is one example.) Suppose Task A does a seek, 
which takes a few hundred milliseconds. While it is waiting, 
other tasks are running. Now suppose that Task B tries at this 
moment to access the disk. It issues its own seek command, 
conflicting with the command issued by Task A. When the 
seek completes, and Task A resumes, it will be at the wTong 
\ocalion onXhe disk. (Worse, since only orve completion signal 
is issued by the controller, one of the tasks may wait forever for 
its seek to finish.) 

Or consider the on-screen clock and cycle counter examples: 
while one task had altered the display cursor, other tasks had 
to be prevented from using it. 

Or consider the printer. If one task ~ maybe a background 
printing task ~ is outputting to the printer, we certainly don't 
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want another task sending output at the same time. 

In the example programs we used the crude solution of switch- 
ing off the multitasker. This is usually not practical - it defeats 
the whole purpose of multitasking! We need a better solution. 

Fortunately, this "mutual exclusion" is a classic problem in 
computer science, and several solutions have been devised over 
the decades [TAN87]. One of the simplest and most elegant 
is the "semaphore," invented by by E. W. Dijkstra in 1965. 

The semaphore 

In its simplest form, a ' 'binary semaphore' ' is a flag associated 
with a resource. Two operations act on semaphores: WAIT 
and SIGNAL, WAIT checks to see if the resource is available. 
If so, it is marked "unavailable"; if not, the CPU is released 
to other tasks until the resource becomes available. SIGNAL 
just marks the resource "available." 

In Forth, these can be written 

: WAIT ( addr - ) 

BEGIN PAUSE DUP C@ UNTIL \ wait for nonzero = available 
SWAP I ; \ make it zero = unavailable 



SIGNAL ( addr - ) 
1 SWAP ! ; 



\ make it nonzero = available 



(These are also in screen 3 of the listing.) 

Dijkstra observed that the operations of testing and setting the 
semaphore must be indivisible . In the cooperative Forth 
multitasker, all Forth code is indivisible until a PAUSE is 
executed, so these definitions will work as written. In pre- 
emptive multitaskers, or any application where interrupts can 
affect semaphores, interrupts must be disabled within WAIT 
and SIGNAL (except for the PAUSE). 

It is a subject of some debate whether SIGNAL should include 
a PAUSE. Adding a PAUSE ensures that a task which is 
blocked on that semaphore will be awakened soonest, thus 
maximizing the use of the resource. Sometimes, however, this 
is not what is desired. 

How semaphores are used 

Every task, before using a shared resource, does a WAIT on its 
semaphore, and after using the resource, does a SIGNAL. 
This is sufficient to ensure that only one task can use that 
resource at any time ~ and yet even if one task is blocked, the 
other tasks can run normally. 

The semaphore is defined as a simple Forth variable. The 
semaphore variable must be initialized to a nonzero value, to 
indicate that the resource is initially "available. ' ' This should 
be done when all other variables are initialized: when you load 
the application (on a PC), or as part of the startup code (in an 
embedded application.) 



For the disk example described above, the Forth code may look 

something like 

VARIABLE DISK-SEMAPHORE 

: READ-SECTOR 

DISK-SEMAPHORE WAIT 

SEEK 

READ 

DISK-SEMAPHORE SIGNAL ; 

Now consider the situation with two tasks trying to access the 
disk simultaneously: 



Task A 


Task B, 


WAIT 




SEEK (100 msec) 


WAR' 


READ (100 msec) 


1 

1— -task #2 Is blockedl 


SIGNAL 


1 

SEEK (100 msec) 




READ (100 msec) 




SIGNAL 



Task A performs a WAIT, sees that the disk is available, and 
proceeds to do its SEEK. Task A then waits with PAUSE until 
the seek is complete, so that other tasks can use the CPU. At 
this point Task B requests the disk resource with WAIT. 
Thanks to Task A, the resource is busy, so Task B is put into 
a wait loop ~ waiting not for the seek to complete, but for 
DISK-SEMAPHORE to be set. This won't happen until Task 
A is finished seeking and reading. So, Task A is waiting for 
the disk. Task B is waiting for Task A's SIGNAL, and the 
other tasks in the system are free to use the CPU. 

The beauty of this approach is that the WAIT and SIGNAL 
are identical for all tasks, so they can be made part of the 
common routine READ-SECTOR that all tasks use. 

Semaphores for intertask signalling 

The WAIT operator is general-purpose: it can be used any 
time you need to wait for a RAM location to become nonzero. 
Recall that two of the uses of wait loops are to wait for an 
interrupt to occur, and to wait for a signal from another task. 

To wait for an interrupt, simply WAIT on a variable you have 
defined for the purpose. The interrupt routine then just needs 
to store a nonzero value in that variable. (Often this can be 
done with a single machine instruction, e.g., increment.) 
Waiting for another task is exactly the same, except that the 
other task can use the high-level SIGNAL word to store the 
non-zero value. 

Note that, in these cases, the semaphore should be initiahzed 
to a zero value. 
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Problems with semaphores 



MESSAGE LOCAL ! ; store the message in his IVIESSAGE 



Semaphores are not foolproof. They are susceptible to ' 'dead- 
lock," where two tasks, each having grabbed one of two 
resources, are waiting for the other resource to become avail- 
able. One solution to this is the "monitor," also described in 
[TAN87], which can be implemented if you have semaphores. 

Breaking out of the depths 

What about the problem of "breaking out" of a deeply nested 
program, preserving all of its nesting information, and then 
returning to it at some future time? 

Surprise! This is exactly what PAUSE does! All of the return 
information, temporary variables, etc. which need to be pre- 
served, are all part of the task context. The task context, you 
will recall, is the information which is saved when tasks are 
switched. So, to suspend a task until some future event, simply 
do a WAIT or some other multitasking wait loop. 

Returning to the command processor example: when 1 rewrote 
this apphcation, I created a word KEYPRESS which waited 
~ with PAUSES ~ for a keypress to become available. I also 
converted all of the variables used in command processing to 
user variables. KEYPRESS is used in dozens of places in the 
program, as the command processor works its way through its 
logic tree. The command processing code is written "nor- 
mally," with no special attention given to saving the state, or 
releasing the CPU to other tasks! 



: RECEIVE ( - message taskadr ) 
BEGIN 

PAUSE loop with PAUSE, 

SENDER @ until my SENDER is nonzero 

UNTIL 

MESSAGE @ get the message from my MESSAGE 

SENDER @ get his tasl< adr from my SENDER 

SENDER ! ; indicate mailbox empty & ready 

MESSAGE and SENDER are user variables. (See screen 4 
of the listing for their definition.) The convention here is that, 
if SENDER is nonzero, a message is in the task's mailbox. 
This works because most Forth systems can't have a task user 
area at address 0000. 

SEND sends the given message to the given task. Before it can 
do so, it must be sure that the destination mailbox is empty ~ 
otherwise it would destroy some other mail. So it waits, with 
PAUSES, until the destination task's SENDER variable is 
zero. Then it stores the message, and the sending task's 
address (MYTASK), in the destination user area. 

RECEIVE waits for any message to appear, as indicated by 
SENDER going nonzero. It then reads the message and the 
sending task's address. Finally, it clears the SENDER field, 
to indicate that the mailbox is now empty. 

Note that if two tasks try to send messages to the same desti- 
nation, one of the tasks will be blocked until the destination 
task has read its mail! 



Message passing 

Often parallel tasks need to communicate with each other. One 
of the most-used schemes is the "mailbox," an agreed-upon 
place where messages can be left for a task. Mailboxes may be 
statically allocated to each task ~ in which case you must be 
careful to have enough mailboxes - or they can be dynamically 
allocated from a pool. 

Perhaps the simplest scheme, which ensures that there are 
sufficient mailboxes for all the tasks, is to include a mailbox in 
each task's user area. Then, as tasks are added, new mailboxes 
are too. Each task can reach its own mailbox easily, as a user 
variable. Other tasks can reach that mailbox by offset from the 
given task's address. (Recall that the ' 'task address' ' is usually 
the base address of its user area.) 

For simplicity, we can limit messages to a single cell (16 bits 
on the IBM PC). An F83 implementation of this would be: 

: SEND ( message taskadr ~ ) 

MYTASK 

OVER SENDER LOCAL get adrs of destination's SENDER 

BEGIN 

PAUSE loop with PAUSE, 

DUP @ until his SENDER is zero 

0= UNTIL 

I store my adrs in his SENDER 



This is a very simplistic message system, although adequate for 
many apphcations. More sophisticated schemes allow a re- 
ceiver to select only messages from a specific sender, or allow 
multiple messages to be queued at the receiver so that multiple 
senders do not have to wait. Other extensions would allow 
variable-length or string messages. 

Example #3: the Print utility 

Screen 5 shows a simple use of messages. This is a modifica- 
tion of F83's screen-printing utility SHOW, to run as a "back- 
ground" task. Load this screen, and type 

START-SHOW 

to activate the printing task. (Don't forget to turn MULTI on.) 
At this point, nothing will happen. You can now type 

1 4 SHOW 

and a printout of screens 1 to 4 will start on the printer. At the 
same time , you will get the ' 'ok' ' prompt on the screen, and you 
can type Forth commands. Type WORDS, for instance. 

When the printing task was activated, its first action (in START- 
SHOW) was to clear its mailbox. It then waits for two 
messages in a row, which it expeas to be the first and last 
screen to print, respectively. (We don't care who sends these 
messages, so the sending task address is DROPped after each 
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RECEIVE.) Since no message has yet been sent, it just waits 
forever, invisible to the "main" Forth task. 

SHOW is redefined to simply send two messages to the print- 
ing task. So, when the SHOW command is typed at the 
keyboard, the printing task is awakened and begins to print the 
requested screens. When the listing is complete, the printing 
task loops, waiting for a new print request (two more mes- 
sages). 

If you have a slow printer with a small buffer, you will notice 
occasional interruptions in the WORDS listing being dis- 
played by the main task. This might appear as if the multitasker 
is not woridng as advertised. Actually, this is an unfortunate 
byproduct of the MS-DOS printer routine. MS-DOS assumes 
that a program which is printing can afford to wait, so there is 
no BIOS call to test the "printer ready" flag. All Forth can 
do is request a character be output to the printer. If the printer 
is not ready, MS-DOS (not Forth) will tie up the computer 
while it waits for the printer. To fix this problem, we would 
have to bypass MS-DOS and write our ovm direct printer I/O 
routines. 

Advanced topics 

The round-robin, cooperative multitasker which has been de- 
scribed is the most common Forth multitasker. Most public- 
domain Forths and many commercial Forths use this approach 
~ it's simple, versatile, and efficient. But some Forth systems 
have extended the multitasker to add new capabilities; and 
most non-Forth multitaskers offer some of these "advanced 
features." 



b) words such as WAIT and SIGNAL become more compli- 
cated, since they must switch interrupts off to be indivisible. 

c) since Forth code is no longer "normally" indivisible, many 
more semaphores are needed to enforce mutual exclusion, and 
more temporary variables must be moved into the user area. 

Prioritized multitaskers 

Another problem is: how do you tell the system that some tasks 
are more important than others? 

Perhaps you want to allocate more CPU to one task than 
another. Or, it may be desirable to run one task in preference 
to all others, as long as it's not waiting for an event. Or 
possibly there is a "background" task which should only run 
when no other task is able to run (i.e., when all the other tasks 
are waiting for something). What you need is a way to assign 
priorities to tasks. High-priority tasks should run in preference 
to low-priority tasks ~ either by receiving a bigger share of the 
CPU time, or by taking the CPU completely away from lower- 
priority tasks. 

Priority schemes are usually associated with preemptive 
multitaskers, but this need not be the case. Here' s one possible 
modification to the basic Forth multitasker to implement a 
priority scheme: instead of PAUSE switching to the next task 
in the round-robin list, make it switch to a designated "first" 
task in the list. This task then is the highest-priority task; as 
long as it is able to run, no other task will get service. WAIT 
must be modified to link to the "next' ' task in the round-robin 
list. 



Preemptive multitaskers 

The problem with cooperative multitaskers is that each task 
keeps the CPU until it does a PAUSE. It can be very difficuU 
to distribute CPU time equally among the tasks; poorly written 
code can "hog" the CPU for inordinate amounts of time. 
Placement of PAUSE instructions becomes something of an 
art. 



The disadvantages of priority schemes are: 

a) there's usually more overhead involved in task switching, 
since the multitasker must decide which task to run next. 

b) assigning priorities is not simple. Sometimes a small 
change can have a disproportionate effect on the amount of 
CPU time various tasks receive. 



One solution is to allow a task switch to be forced upon a task, 
say by a real-time clock interrupt. If tasks are switched every 
10 milliseconds, it's easy to allocate CPU time accurately. This 
also ensures that no task can tie up the CPU; and in a round- 
robin system, it guarantees an upper bound on how long a task 
must wait for the CPU. 

Preemptive multitaskers have several disadvantages, too: 

a) since a task switch can occur at any time ~ even in the 
middle of a CODE word ~ all of the CPU registers and flags 
need to be saved with the task context. On a big processor like 
the 68000, this can make the context switch time much longer. 
(Recall that the cooperative multitasker only needs to save four 
registers.) 



c) in some systems, it's possible that some tasks will never get 
any CPU time. 

Interrupts 

How interrupts are handled can vary from one multitasker to 
another. 

The simplest approach is to treat interrupts completely apart 
from the multitasker. Interrupts do not affect the execution of 
tasks; when an interrupt occurs, the interrupt routine executes, 
and then returns to whichever task was miming. (I.e., inter- 
rupts work the same as they do in a non-multitasking system.) 
Interrupts can set flags which will later be seen by various 
tasks. This approach works best when the interrupt handlers 
can be kept simple. It offers the fastest interrupt service time; 
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however, if the purpose of the interrupt is to ' 'wake up' ' a task, 
it may be many milliseconds before that happens. 

A preemptive multitasker can allow an interrupt to wake up a 
specific task. If the service to be performed is complex - say, 
interpreting a long message received via DMA — then it's 
usually better to do that service in a task, rather than in an 
interrupt handler. (This is because, usually, some or all inter- 
rupts are blocked for the duration of an interrupt handler.) The 
downside: in addition to the disadvantages of preemptive taskers, 
this approach has a longer interrupt service time, since the 
interrupt handler is more complex. 

There are other variations, but most interrupt service schemes 
fall loosely into one of these two categories. 

Conclusion 

Multitasking is a powerful tool, and like a good tool, it can 
dramatically increase your productivity. The basic Forth multi- 
tasker is more than adequate for many applications. Like Forth 
itself, it is simple, versatile, and efficient... and easy for one 
person to grasp. Add multitasking to your ' 'toolkit' ' : you will 
find that many programming problems become simpler, and 
some become trivial! 
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Screen 1 

\ MULTITASKER EXAMPLE 1 - ON SCREEN CLOCK bjr09sep92 

CODE ©TIME ( - h m s) HEX 2C # AH MOV 21 INT AH AH SUB 

CHALMOV AX PUSH (hrs) CLALMOV AX PUSH (mins) 

DHALMOV 1PUSH (sees) END-CODE 
CODE @CURS ( - n) # BH MOV 3 # AH MOV 10 INT DX PUSH 

NEXT END-CODE 
CODE !CURS ( n -) DX POP # BH MOV 2 # AH MOV 10 INT 

NEXT END-CODE 
: .TIME ( h m s -) <# # # 3A HOLD NIP # # 3A HOLD NIP 

###> @CURS>R 48ICURS SINGLE TYPE MULTI R> ICURS ; 

HEX 400 TASK: SCREEN-CLOCK 

: START-CLOCK SCREEN-CLOCK ACTIVATE 

DECIMAL BEGIN ©TIME .TIME PAUSE AGAIN ; 
: STOP-CLOCK SCREEN-CLOCK SLEEP ; 
DECIMAL 

Screen 2 

\ MULTITASKER EXAMPLE 2 - ROUND-ROBIN CYCLE COUNTER 

VARIABLE CYCLES CYCLES! HEX 
:. CYCLES 1 CYCLES +! CYCLES© 
©CURS >R 40 ICURS SINGLE 6 U.R MULTI R> ICURS ; 

HEX 400 TASK: CYCLE-COUNTER 

: START-COUNTER CYCLE-COUNTER ACTIVATE 

DECIMAL BEGIN CYCLES PAUSE AGAIN ; 
: STOP-COUNTER CYCLE-COUNTER SLEEP ; 
DECIMAL 

Screen 3 

\ SEMAPHORES IN F83 bjr09sep92 

: WAIT ( addr - ) \ WAIT for semaphore ready 

BEGIN PAUSE DUP C@ UNTIL \ wait for nonzero = available 

SWAP ! ; \ make it zero = unavailable 



: SIGNAL (addr - 
1 SWAP ! ; 

Screen 4 



) 



\ SIGNAL that semaphore is ready 
\ make it nonzero = available 



\ MESSAGES IN F83 bjr09sep92 

USER VARIABLE MESSAGE \ a 1 6-bit message 

VARIABLE SENDER \ holds address of the sending task 
FORTH 
: MYTASK ( ~ a) UP © ; \ returns addr of the running task 

: SEND ( msg taskadr - ) \ send msg to the given task 
MYTASK OVER SENDER LOCAL \ - msg taskadr mytask SENDERadr 
BEGIN PAUSE DUP © 0= UNTIL \wait until his SENDER Is zero 
! MESSAGE LOCAL ! , \ store mytask.msg in his user var 

: RECEIVE ( ~ msg taskadr) \ wait for a message from anyone 
BEGIN PAUSE SENDER © UNTIL \ wait until my SENDER nonzero 
MESSAGE © SENDER © \ get message and sending task 
SENDER I ; \ now ready for another message! 

Screen 5 



\ MULTITASKER EXAMPLE 3 - BACKGROUND PRINT UTILITY 

HEX 400 TASK: SHOW-TASK 

: START-SHOW SHOW-TASK ACTIVATE 
DECIMAL SENDER ! \ must clear message buffer first 
BEGIN 

RECEIVE DROP RECEIVE DROP \ - first last 

SHOW 
AGAIN ; 

: STOP-SHOW SHOW-TASK SLEEP ; 

: SHOW (first last-) 

SWAP SHOW-TASK SEND SHOW-TASK SEND ; 
DECIMAL 
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FIGURE 1. TASK CONTEXT 
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Computer Corner 



Editorial Comment 



By Bill Kibler 



UZIandZ180 



Well another issues is done and ready 
for the press. It is late and I need to whip 
this out so I can finish the issue. Yet I 
actually do have items of importance 
(depending on your point of view) to 
comment on. 

UZI on a Z180? 

Rick Rodman's column this month got 
me thinking about the UZI program 
(Unix 7 for the Z80). The intro 1 in- 
cluded pointed out problems with such a 
hmited memory space. That sort of ruled 
out doing much with it, until 1 consid- 
ered the Z180, It would appear tliat a 
little re-working is in order, and major 
problems might be solved when it has a 
fiill Megabyte of memory for swapping 
instead of using the disk. Something we 
need to consider. 

Speaking of the Z 180, 1 have gotten some 
feed back on our proposed XT bus Z180 
CPU card. So far the results is vary fa- 
vorable. Everyone is in favor of it, ex- 
cept price seems to be a major concern. 
It would seem our competition is cheap 
clones that are falling into the $100 range 
and under. My position is still, that we 
are offering much more than you will 
get by buying that old clone. 

What options, well 20MHZ CPU that 
would require at least a 40MHZ 386 to 
be as fast. Source code to operating sys- 
tems and many utilities. Many times sim- 
pler design. Access to very cheap I/O 
cards. Ability to use LAN cards and other 
exotic I/O devices. Lots of boards that 
can be bought for $5 to play with and 
modiiy. 

Of course you say, but why not the XT 
itself My answer is go ahead and try. I 
spend many hours a week working on 



adapting PC/XT software and hardware 
for a living, and let me say without a 
doubt it is no fun! I hate anything that is 
written by Microsoft. The list of bugs in 
those products is endless. The problem 
is there is no way to work around most 
of those bugs. What is in store for the 
future, more complex problems and bugs. 

So my position is the simpler the better. 
Z 180 on a XT bus is simple and straight 
forward. I like that. Windows for 
Workgroups, however is another suc- 
cessful dog from Microsoft. 

Windows for Workgroups 

Well last week I set through four hours 
of seeing just how Windows for 
Workgroups works. It becomes very ap- 
parent that the main objective is kilhng 
any competition. The product contains 
something to compete with ahnost every 
vendor of LAN products. It contains mail 
programs, LAN interfaces, schedule pro- 
grams, their new database products, and 
on into nausea. 

The market is targeted at small busi- 
nesses (2 to 5 users) with the idea of 
eliminating sneaker nets (that is when 
disk data is transferred in person from 
machine to machine). Yet the $25 net- 
work (1-800-628-7992 and tell them The 
Computer Journal sent you) can do the 
same thing with less overhead and no 
need for windows. I would say my pro- 
ductivity drop by 30% thanks to waiting 
for windows to do it's thing. Now do it 
all with a Z180 and a few serial ports 
and now we are talking simple and fast. 

Z80 on a LAN? 

One area I am looking into is tying CP/ 
M systems together. Now most servers 



are MSDOS based (actually 0S2 for 
LanMan or Netware for the other 70%.) 
And when it comes for raw storage the 
cost ratio for a newer PC based machine 
is definitely better than any other. So it 
only logically makes sense to use them 
for servers. Now to use a 386 with 8 
Megabytes of memory for a word pro- 
cessor seems to be a little overkill to me. 

A better alternative would be using a 
Z80 based machine, tuned for word pro- 
cessing and connected to the PC server. 
This seems a great ratio and balance of 
simple and complex ways to solve prob- 
lems. The large and virtual nature of the 
server balances the speed and simplicity 
of the Z80 for handling characters on a 
screen. 

I guess one area to consider is how about 
graphics on a Z80. When I look at how 
most of the more recent word processor 
are more like desktop publishers, I really 
don't see a problem. I even know of one 
magazine published solely on a PC based 
word processor. So in reality I find little 
that could not be done with a CP/M 
talking to a MSDOS server. So where is 
that old LAN hardware and software 
that started out on Z80s? There should 
still be some of the old code and prod- 
ucts kicking around. Anybody got any? 
let me know will you. 

Well I need to save room for the Kaypro 
disk catalog, so I hope you consider the 
Z 180 on a PC bus and drop me or Herb 
a note about your ideas. Till later keep 
on computing. 
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MODEMPAT sets up the SIO (serial port) for whatever baud rate, bits 

per character, stop bits, ar\d parity you need. 

M0DEM7+ This is MODEM7 with the MODEMPAT akeady added so 

you can select the correct communications interface each time you enter 

M0DEM7. 

NOTE: See disk K28 for a later version of Modem 7. However, the disk 

K28 version limits you to 300 or 1200 baud. This Modem 7+ gives you the 

complete range from 300 to 9600 baud. 

KMDM795 A superset of M0DEM7, this program lets you set baud rate 

on the fly. However, it is not set up for changing the bits/char and such 

likeMODEM7+. 

TERM A disassembly of the TERM program that was distributed with 

the early KAYPRO lis and 4s. With this commented source, you can 

configure it for your own needs. 

SQUEEZE/UNSQUEEZE These programs squeeze and imsqueeze all 

kinds of files. 
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FORMFEED Run this program when you need a form feed on your 

printer. 

DIR-DUMP Displays all the disk files and their locations, along with the 

user number. 

D This super directory program produces an alphabetical list in vertical 

order. 

WASH A file transfer/maintenance program. Forerunner (and subset) of 

SWEEP. 

DUMPX Similar to the CP/M routine DUMP, DUMPX is incredibly 

more fwwerful and more useful (e.g. displays the ASCII equivalents). 

SUPERSUB A definite improvement over CP/M's SUBMIT program. 

ALLOC Produces a bit map of the disk and can write-protect files. Menu 

driven. 

COMPARE Compares two files. 

DU-77 Very powerful disk utility. The user interface isn't particularly 

easy to learn but you can do anything to a disk with this famous 

program. 

USTT Prints out CP/M files with headers, p)age numbers, and offsets 

from left margin. 

DASM True Zilog format disassembler for 8080 and Z80 object iCXM) 

files. 

UNSPOOL Lets you use your system and print at the same time 

(without one of those fancy print buffers). 

FINDBD54 This super utility really checks a disk (without destroying 

the data on it) and reports bad sectors. 

CATALOG A group of programs to create and maintain a directory of 

all the programs you have on all your disks. 

UNERA Unerases files. Kinda handy. 
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PACMAN Almost the real thing! And on a system that has no graphics! 

ZCHESS A real honest-to-gosh, competent (at least more competent than 

D chess game with a 1 to 6 level look-ahead. 

OTHELLO Othello is a game you leam in minutes, and master in years. 

GAMES Seven games all put together as one program. You select from 

UFE, HORSE RACES, MAZE, PATTERNS, BLACIQACK, ANIMAL, and 

GO-BANG. 

VVUMFUS Wumpus is a dassic computer game. You have a choice of 

caves as you enter and you can map them as you go through. 

FRESSUP Pressup is somewhat similar in play to Othello but is not as 

difficult to master. 

MM "Rus is the Master Mind game. You try to guess what characters the 

computer has chosen. Tlie point of the game is to guess the characters in 

as few moves as possible. 

BIO Generates Worhythm charts. This handy program does it all, 

complete with a graphic display of the results. 

MAZE Generates random mazes (surprise!). 
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ADVENTURE Here it is! The latest, greatest, most cussed adventure 
ever devised by half-mortals. This cave is greatly expanded and the 
creatures are much smarter (smarter than I anyway). Tliese files total 
191K 80 there Isn't room for the usual documentation. See 
ADV-SAVE.DOC on disk K-3 for documentation. 
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Don Brittain has oeated this graphics display package for use with 
MX-80, FX-80 and FX-1(» with Graftrax. or Ckmini lOX printers. 
GRAF An Interactive routine that allows you to create graphic images. 
NOTE: You get the graphics on the printer wily. Even the new Kaypros 
cannot di^lay the kind of high-resohition gr^hics that this package can 
do. The .COM. files win work with ^json MX-«0 compatible printers 
cnly. If you are familiar with C and have Aztec C you can try modifying 
and recompiling the source to match a different printer. 
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ROFF A UNIX-like text formatter. 

SIGNS creates large block letters on your printer. 

EPSMODE4 Set print modes on your Epson MX80, 

EDIT Full-blown line editor similar UNIX's EX. 

CHOP cuts off a file after n bytes. CP will copy from one file or device to 

another. DUMP outputs (to screen, disk, etc) the HEX translation of a 

file. MS lets you specify how many linefeeds you want between lines 

(multiple space). WRAP is a simple formatter. 

ENTAB replaces blanks with tabs wherever possible. 

RTW removes trailing whitespace from a text file. 

TRUNC truncates each line in a text file at a specified column. 
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10k 


LIB 


B • 


Ik 


SIDIQA 


B 


Ik 


CRC 


COM* 


3k 


LIBA8M 


c 


Ik 


STROIP 


C 


> Ik 


CRCKLIST 


CRC* 


2k 


OCT 


c 


Ik 


UTOI 


C 


> Ik 


DTOI 


C • 


Ik 


PRIHir 


c 


2k 


VM 


B 


• Ik 


BIUO 


C * 


Ik 


SAMPLE 


DOC 


7k 


VML 


B 


• Ik 


RBUiO 


HEX* 


Ok 


aicN 


C 


> Ik 


XTOI 


C 


. Ik 


lOLIB 


ASM* 


2Ck 


BNAT.TA 


DOC 


. 17k 








IIOC 


C * 


Ik 


8NXLLC2 


DOC 


• 6k 








ITOC 


c • 


Ik 


SMS 


COM 


• 35k 









Here is an expanded version of Ron Cain's &nali C The additions to the 
language are substantial and include such important features as I/O 
redirection on STDIN and STDOUT, separate compilation of version 2 
modules and many new library functions. 

K-8 

SOURCE OF SMALL C VERSION 2 



ABS 


C < 


u 


CC33 


> 


Sk 




C • 


Ik 


cc 


DBFi 


4k 


CC4 


C < 


Ik 


001 


C • 


Ik 


cci 


e • 


6k 


CC41 


C • 


7k 


PRXRr 


C • 


2k 


coil 


C < 


Ilk 


CC42 


C < 


9k 


SI«I 


C • 


Ik 


CC12 


c 


8k 


CC80 


DEr< 


U 


SMK 


DET* 


4k 


0C13 


c 


8k 


CBC 


COM 


3k 


SBIOA 


H • 


Ik 


CC2 


c 


2k 


CBCKLI8T 


CRC 


2k 


sncaip 


C * 


Ik 


CC21 


c 


7k 


DTOI 


C 


Ik 


DTOI 


C • 


Ik 


CC22 


c 


• 9k 


ITOD 


c 


Ik 


XTOI 


c • 


Ik 


CC3 


c 


> 2k 


ITOn 


C 


> Ik 








CC31 


c 


> 9k 


ITOX 


c 


• Ik 








CC32 


c 


> 6k 


LETT 


C 


. Ik 









K-8 contains the source of Small C version 2. You do not need this disk to 
use the compiler on K7. 
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K-9 














GENERAL UTILITIES 










>-Din DOC* 


4k 


■X14 


CCM 


3k 




Ik 




14k 


EZ14 




a 


VMfllORD UM* 


•k 




3k 


KX14 


■DB 


5k 


fAsawOIID CON* 


Ik 


cw: OCM 


3k 


1X14 


m 


Ik 


MKOOn SXT 


3k 


GKaCLIR CBC 


Ik 


rm 


MM* 


•k 


■•ID2 CCM 


Ilk 


D OCM 


3k 




COM* 


Ik 


now OCM* 


27k 


Dir/UD DOC 


Sk 


roR) 


DOC* 


Ik 


leVK DOC 


Ck 


Dir2 OOM 


15k 


FIX 


COM 


2»k 


tcrt Bx 


Ck 


Ba4 MH 


29k 


nx 


DOC 


Ik 







EX14 Great replacement for both SObMIT and XSUB. 

FIX A fantastic disk utility that allows you do nearly anything on a disk. 

FIND Searches the disk for a string of iqypercase characters. 

PASSWORD aUows you to password-imtect files. 

ALIENS Space Invaders patched for the Kaypro. 

TREK You finally get a chance to ccanmand the Starship Enterprise. 

ZCPR TWs CCP replacement will loc* on drive A for a COM file when 

you're log ged in on drive B, page during TYPE, and more. 

DO NOT ATTEMPT TO INSTALL ZCPR ON THE KAYPRO 10! 

DJF2/SSED With these utilities you can update someone else's copy of a 

program by simply creating a file of the updates (using TXFl) and then 

sending only the differences. 

K-10 

Z80 AND LINKING ASSEMBLERS 



10-DZ8K DOC 


3k 


CKMICFM DOC 


■k 


LMM DOC 


5k 


ac oat 


3k 


csoncm vu 


Ok 


ttuanM ASM 


5k 


CBcxLin ate 


Ik 


CBomcni ISO 


143k 


ruanu com 


Ik 


aancM com 


8k 


IMM OOM 


Ck 







CROWECPM If you've been looking for a good, basic Z80 assembler for 
S8, this is it. We modified the CROWE assembler so that it would work 
on any CP/M system. Source code is included so you can extend it to 
your heart's content. 

LASM A faster, linking, rewrite of tfie standard C7/M ASM assembler. 
FRINTPRN lUs is a nice Utile program that makes it possibk! to list the 
JRN files produced by the CROWECPM assembler on any printer. 

K-11 

CHECKBOOK PROGRAM - LIBRARY 

UTILITIES 



u-Dzn 


DOC* 


3k 


IXUBL 


en* 


u 


ur 


OOM* 


18k 


rMTTi 


OOM* 


10k 


KXM0L 


DOC* 


a 


ur 


DOC* 


23k 


cncn 


DOC* 


l»k 


EXAMTL 


■Ul* 


2k 


UDiri 


DOC* 


7k 


I'^yp^f 


tso* 


54k 


lOZIt 


COM* 


6k 


leut 


OOM* 


•k 


ate 


OOM* 


3k 


LDU 


DOC* 


3k 


fSUT 


DOC* 


Ik 




CRC* 


Ik 


UIR 


UR* 


13k 


VUR 


COM* 


2k 


DICTLkX 


COM* 


3k 


LZUtAlZ 


Uk* 


Ik 


VUR 


DOC* 


a 


Dinux 


OOC* 


3k 


unm 


COM* 


2k 









DISPLAY is like ttte TYPE command except it allows you to page 

forward or badcward. 

VLIST uses the cursor keys to vary the scrolling qwed of a fUe you are 

TYPEing. 

GLST ref(»inats a long text file of short wckIs into columns. 

CHECKS keeps trade of «Mdi diedcs are tax deductaUe and vMch 

should be cjiai^ed Id various accounts. It also keeps a nmning balance. 

LU (LIBRARY UTILITIES) lUs combinatlan of utilities allows you to 

extract individual files or run COM files from ttte library wittiout 

extracting them first Y(M can also build your own Ubraiy files. 



K-12 

KAYPRO FORTH 



12-DIBK DOC* 2k 
CKC COM* 3k 

dtdCLIST CKC* Ik 



rCMTH COM* 7k 
rORTB DOC* 12k 

rORTB SCR* 150k 



XrORTH COM* ICk 



There are two FORTHs on this disk. FORTH is true Fig FORTH. 
KFORTH has been extended and includes its own saeen editor, 
decompiler, and 8080 assembler. 

K-13 

SOURCE FOR FIG-FORTH 

rORTH COM 7k 



13-DISK 


DOC 


Ik 


CRCKLISI CRC 


Ik 


CRC 


CON 


3k 


FORTH ASH 


4Sk 



This disk contains the source of the Fig FORTH on disk K12. 

K-14 

SMARTMODEM PROGRAMS 



14-DISK 


DOC 


3k 


MOCIMPAT 


ASM 


»k 




MAC 


83k 


sn 


CCM 


2k 


MOOINFAT 


COM 


12k 


XMODKM 


COM 


4k 


CRC 


COM 


3k 


RHOHI 


001 


Ik 


XMODEM 


DOC 


9k 


CRCKLISt 


CRC 


Ik 


tsosi 


BAK 


Ik 








D 


COi 


3k 


SMODIN 


DOC 


24k 








KAYTERM 


DOC 


5k 


8N0DIMK 


COM 


10k 









SMODEMK Modem? setup for the Kaypro and SmartModem. 
XMODEM lets a remote user upload and download files. 
BYE connects and disconnects your system from the phone line. 



K-15 














HARD DISK UTILITIES 










15-DISK DOC 


6k 


CRCKLIST CRC 


Ik 


MDLTCOPy 


CX3M 


2k 


Bl COM 


Ik 


D COC 


3k 


MOLTCOPy 


DOC 


Ik 


BACXtff ASM 


31k 


FLOPCOPy ASM 


17k 


SWEEP 


COM 


28k 


BACKU? COM 


«k 


FLOPCOPY can 


3k 


SIISEPSS 


DOC 


14k 




7k 


FLOPCOPy DOC 


2k 





ASM 


4k 


BISBORST ASM 


12k 


MAKZ COM 


3k 


D 


COM 


Ik 


BICBORST COM 


2k 


MDIR ASM 


10k 


DMSQ 


CCM 


12k 


BISBDRST DOC 


3k 


MDIR COM 


Ik 








CRC COM 


3k 


MOVI COM 


Ik 








CRC DOC 


Ik 


MtttTCOPy ASM 


14k 









BACKUP is a lifesaver. It backs up yoiir hard disk onto as many floppy 

disks as necessary. 

FLOPCOPY makes it easy to back up floppy disks on a system with one 

floppy drive and a hard disk. It uses the hard disk as a buffer. 

BIGBURST breaics apart any file that is too large to fit onto a floppy in 

one piece. 

MULTCOPY operates like PIP, but will prompt you when the floppy is 

full so you can change floppies. 

MDIR This directory program displays files under ALL user areas and 

alphabetically sorts the entries in each area. 

MAKE/MOVE Two utilities for moving files between user areas. 

U lets you change user area and drive with one command. 

SWEEP lets you do nearly everything you normally do with PIP, only 

easier. It's like TYPE, ERA, DIR, and PIP in one program. 
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K-16 

PASCAL COMPILER 



K-SISK 


DOC* 


Ik 


BHSDATA 


• 




P STACK 


DOC. 


2k 


COMTMUC 


C(»l- 


2k 


FkSCU. 


DOC" 




KBSEH 


DOC* 


3k 


CRC 


COM* 


3k 


PASTtHTAX 


DOC. 




RTP 


ASM. 


Ilk 


CRO 


DOC. 


Ik 


PC 


SUB. 




RTP 


COM. 


2k 


CRCXLIST 


CRC. 


2k 


PKT 


COM* 




STIRLnC 


CCW- 


2k 


DISK 


DOC. 


3k 


trti 


PAS* 


Ilk 


8TIRLI3)S 


PAS. 


Ik 


«Q 


COM> 


3k 


PLAirCATA 


. 




TtSTIR 


PAS. 


4k 


■Q 


t\8' 


2k 


PLAYKAL 


PAS. 


13k 


VALIDA3I 


SUB* 


Ik 


BC14 


cot* 


3k 


POPS 


DOC. 




XA 


oco. 


Ik 


■X14 


DOC. 


Ck 


POWTWO 


PAS. 




XA 


PCO. 


Ik 


mo 


tliS' 


Ik 


PPG 


c««. 


16k 








BH5 


COM* 


6k 


PPC 


DOC. 


12k 








BUS 


PAS. 


15k 


PPC 


PAS. 


26k 









As it stands, this version of Pascal supports only a subset of the language, 
but since the disk also contains complete source for the compiler, you can 
extend it if you wish. The compiler is written in Pascal and it compiles 
itself. 



K-17 










Z80 TOOLS 










17-DlSK DOC. 2k 


DASM DOC. 


27k 


XLATE2 


DOC. 3k 


CRC con. 3k 


DASM MAC* 


74k 


XIATE2 


MAC 37k 


CRC DOC. Ik 


DASMZLG MAC. 


17k 






CRCKLIST CRC Ik 


DISASMBL DOC. 


Sk 






DASM COM* 10k 


XLATE2 COM. 


5k 







XLATE2 translates 8080 assembly language programs into Z80 

mnemonics. 

DASM is a friendlier version of the disassembler on disk K2. 

K-18 

SYSTEM DIAGNOSTICS 



lODSKTST 


a»i 


3k 


DISKALSH 


MAC 


9k 


MDIASITY 


COM 


4k 


18-DISK 


DOC 


2k 


DISKTIST 


DOC 


Ilk 


MDIAGTTY 


MAC 


36k 


2DISKIST 


COM 


3k 


DISKTISI 


MAC 


24k 


MDIAGXXX 


DOC 


13k 


4DIBKI8I 


COM 


3k 


KWLPT 


COM 


4k 


MZMRS 


ASM 


21k 


CRC 


COM 


3k 


i-araTY 


COM 


«k 


MDCR5 


COM 


2k 


CRCKLI8T 


CRC 


Ik 


MDIAGLPT 


con 


4k 


MEMRS 


DOC 


7k 


OIBKALai 


COM 


Ik 


MDIAGLPT 


MAC 


36k 









MEMRS performs a number of memory diagnostic tests from about 

lOOOH to the bottom of BOOS (the TPA). 

MDIAGTTY/MDIAGLPT Two programs to test from lOOOH to the top 

of memory. TTie test procedures are different and a bit more exhaustive 

than those in MEMRS. 

LOWTTY/IOWLPT Revisions of MDIAGTTY and MDIAGLPT that test 

the portion of memory that is not tested by the others (OOOOH to lOOOH). 

DlSKTSTNice little disk diagnostic which doesn't require an alignment 

disk or scope. 

DISKALGN simply positions your drive head to a specified track. This 

makes ahgnment with a standard analog alignment disk much easier 

(you still need an ahgnment disk, a scope and a manual). 



K-19 

PROWRITER GRAPHICS SOFTWARE 



19-DISK 


DOC 


Ik 


CBAT C 


8k 


HDCH 


CRT 


12k 


BARl 


CRT 


2k 


CRAT COM 


41k 


LIKE 


SRP 


3k 


BAR2 


CRT 


2k 


eRAT DOC 


21k 


MZDIOM 


GRF 


4k 


CIRCLE 


SRjr 


Sk 


CRATCIRC C 


2k 


CMALL 


GRT 


Ik 


CRC 


COM 


3k 


GRAITILE C 


2k 


STAR 


GRF 


8k 


CRCXLIST 


CRC 


Ik 


CRAriHvrr c 


2k 


TITLE 


CRT 


8k 


D 


CON 


3k 


CRAIXINI C 


2k 








DIMO 


c 


7k 


GRAI-PLOT C 


2k 








DEMO 


cm 


3Sk 


BRArUTIL C 


5k 









Don Brittain's Prowriter version of disk K5. See the documentation on 
that disk for more information. 

K-20 

PROGRAMS FOR MICROSPHERE'S COLOR 

GRAPHICS BOARD 



20-DI8K 


DOC 


2k 


PACIHIT 


C 


Bk 


PIE 


DOC 


2k 


CRC 


CC»( 


3k 


PACKAH 


C 


7k 


PORTS 





Ik 


CRC 


DOC 


Ik 




COM 


24k 


SKETCH 


BAS 


26k 


CRCXLIST 


CRC 


Ik 


PACMAN 


SCR 


14k 


SKETCH 


COM 


19k 


RIGBBCR 


PAC 


Ik 


PACMOHST 


C 


Sk 


SKETCH 


DOC 


6k 


PAC 




Ik 


PACDTIL 


c 


£k 


BKXTCB 


SCR 


14k 


PAC 


SUB 


Ik 


PIE 


BAS 


9k 


TSXT 


OCT 


10k 


FACDETS 


H 


3k 


PIE 


cm 


26k 









SBASIC Pacrnan, sketching, and pie chart programs for the color 
graphics board. 

K-21 

SBASIC PROGRAMS AND SCREEN DUMP 



ADDRESS 


DAT 


Ok 


DaMC84 


MAC 


8k 


MSTRMIND 


COM. 


12k 


CRC 


COM* 


3k 


HANGMAN 


COM 


21k 


SCREEN 


BAS. 


2k 


CRCKLISI 


CRC 


2k 




DOC 


2k 


SCREEN 


CON. 


Bk 


DIR+ 


COM. 


4k 


INSCRZEN 


BAS 


6k 


SCREEN 


DOC. 


Ik 


DIR+ 


DOC 


Ik 


INSCREEN 


COM 


Ilk 


SCROLL 


COM. 


Ik 


DRIVSR 


BAB. 


12k 


INSCRZEN 


DOC 


9k 


SCROLL 


DOC 


2k 


ORIVXR 


COM* 


13k 


MATH 


BAS. 


4k 


WORD 


COM 


8k 


DRIVER 


DOC 


3k 


MATH 


COK' 


9k 


WORD 


LIB 


Ik 


DtniP24 


COM 


Ik 


MATH 


DOC. 


Ik 


XLATE 


BAS. 


2k 


DtniP24 


DOC 


3k 


MATUl 


BAS. 


3k 


XIATE 


COM. 


5k 


Dt)MP24 


MAC 


6k 


MATHl 


COM. 


13k 


XLATE 


DOC. 


3k 


DIMP84 


COM 


Ik 


MATHMIND 


DOC. 


Ik 









DIR+ This disk utility does everything PIP does and much more. 

DRIVER creates a menu of .COM files on drives A and B and executes 

selected file. 

DUMP24 Screen to printer dump for older (83) model Kaypros. 

DUMP84 The same as the above program for the new generation 

Kaypros. 

HANGMAN Traditional word guessing game in SBASIC. 

INSCREEN SBASIC screen input program. 

MATH Micro C's attempt at structured SBASIC coding using Math! as 

the victim. 

MATHl The math game in its original unstructured form. 

MSTRMIND Mastermind game written in SBASIC. 

SCREEN displays all displayable screen characters. 

SCROLL allows viewing of files by scrolling forward or backward. 
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